unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* What to do about config.h, etc...
@ 2003-03-04 19:04 Rob Browning
  2003-03-04 19:05 ` Andreas Rottmann
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Rob Browning @ 2003-03-04 19:04 UTC (permalink / raw)



In 1.6 and 1.7, configure has been changed to generate config.h rather
than libguile/scmconfig.h, and now libguile/scmconfig.h is generated
from ../config.h using sed.  During this process sed removes
autoheader's global PACKAGE #define, so that it won't conflict with
any other package's public headers.

This was a quick and ugly hack for the release, and it's only a
stopgap.  We probably need to do something else so that we're not
defining hundreds of fairly generic configure symbols in the global
namespace whenever anyone #includes one of our public headers.
i.e. C_ALLOCA, DEBUG_EXTENSIONS, HAVE_*, SIZEOF_*, etc.

Ideally, the symbols that really need to remain public should probably
be renamed with the SCM_ prefix, and the rest of the symbols should be
moved off to a private header that's only #included by non-public
files.  Of course if anyone has been using any of the symbols we
rename or make private, we may break backward compatibility, so we
need to decide which evil we prefer: namespace pollution, or API
change.

To make things more difficult, AFAICT the auto* tools don't really
provide us with any easy mechanism to fix this problem.  Off the top
of my head I can see three choices:

  - Edit configure.in to change all symbols produced by configure to
    have SCM_ prefixes and just keep #including a copy of the
    automatically generated header (i.e. no private symbols) as we do
    now.  The main disadvantages to this approach are that we have to
    do a lot of editing of configure.in to override default behaviors,
    (i.e. we can't use AC_CHECK_FUNCS with multiple arguments as we do
    now), we'll always have to keep an eye on things to make sure
    autoheader doesn't add any new symbols that we have to "fix" in
    configure.in, and we may end up with a lot of global symbols that
    don't need to be global (i.e. are only used in .c files).

  - Use sed or similar to mangle config.h into a public and private
    header (or perhaps to just rename FOO -> SCM_FOO globally).  I'm
    concerned that this approach may be brittle -- trying to sed C
    syntax and not make mistakes seems a little fragile to me, and
    mistakes here may be hard to track down, i.e. symbols that just
    get missed or misdefined may still allow the compiles to proceed
    without incident, even though the code being generated is
    potentially incorrect.  If we did try this approach, we would need
    to make sure that symbols only made it into either the public
    header or the private header so that we don't have conflicts in .c
    files that directly or indirectly include both.

  - Use a C program to translate from config.h to the public and
    private headers, i.e. write a trivial C program that is built at
    compile time, that #includes config.h, and that when run, spits
    out our public and/or private headers.  The advantages here are
    that we're sure that we're parsing config.h properly (unlike with
    the sed approach), and that we have careful control over what
    makes it into the headers, along with the ability to rename
    symbols, etc.  The disadvantage is that it adds some complexity,
    and doesn't allow us to easily copy the documenting comments from
    config.h to our public/private headers.

    As a toy example of this approach.  The C program to generate the
    private header (say scmconfig-private.h) might look like this:

      #include <config.h>

      #ifndef CRAY_STACKSEG_END
      #define CRAY_STACKSEG_END 0
      #endif

      #ifndef SOMETHING_ELSE_ONLY_USED_IN_C_FILES
      #define SOMETHING_ELSE_ONLY_USED_IN_C_FILES 0
      #endif
      ...

      #define PRINT_DEF(SYM) print_if_defined(#SYM, SYM)

      static void
      print_if_defined (const char name[], int defined_p)
      {
        if (defined_p)
          printf ("#define %s\n", name);
        else
          printf ("/* #undef %s */\n", name);
      }

      int
      main (int argc, char *argv[])
      {
        print_preamble (); /* contains copyright header, etc. */
        printf ("\n");
        printf ("/* See config.h for symbol documentation. */\n");
        printf ("\n");
        PRINT_DEF(CRAY_STACKSEG_END);
        PRINT_DEF(SOMETHING_ELSE_ONLY_USED_IN_C_FILES);
        PRINT_DEF(YET_ANOTHER_THING_THATS_ONLY_PRIVATE);
        return 0;
      }

    The code to generate the public header might be similar, but would
    probably be a little more complex since we might also want to
    output some documenting comments for the symbols (as config.h does
    now).  Also, for the public header, we would likely need to rename
    things as well:

      printf ("#define SCM_SIZEOF_INT %d\n", SIZEOF_INT);

Thoughts?  Better alternatives?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-04 19:04 What to do about config.h, etc Rob Browning
@ 2003-03-04 19:05 ` Andreas Rottmann
  2003-03-04 19:53   ` Rob Browning
  2003-03-05  0:55   ` Rob Browning
  2003-03-05 14:18 ` Marius Vollmer
  2003-03-06 22:04 ` Kevin Ryde
  2 siblings, 2 replies; 12+ messages in thread
From: Andreas Rottmann @ 2003-03-04 19:05 UTC (permalink / raw)
  Cc: guile-devel

Rob Browning <rlb@defaultvalue.org> writes:

> In 1.6 and 1.7, configure has been changed to generate config.h rather
> than libguile/scmconfig.h, and now libguile/scmconfig.h is generated
> from ../config.h using sed.  During this process sed removes
> autoheader's global PACKAGE #define, so that it won't conflict with
> any other package's public headers.
>
[snip]

> To make things more difficult, AFAICT the auto* tools don't really
> provide us with any easy mechanism to fix this problem.  Off the top
> of my head I can see three choices:
>
>   - Edit configure.in to change all symbols produced by configure to
>     have SCM_ prefixes and just keep #including a copy of the
>     automatically generated header (i.e. no private symbols) as we do
>     now.  [...]
>   - Use sed or similar to mangle config.h into a public and private
>     header (or perhaps to just rename FOO -> SCM_FOO globally).  [...]
>
>   - Use a C program to translate from config.h to the public and
>     private headers, i.e. write a trivial C program that is built at
>     compile time, that #includes config.h, [...]

If you take a look at how other libraries, (e.g. GLib) do this, you'll
see that most of them that need a public-installed, platform-specific
header, use autoconf's AC_CONFIG_COMMANDS macro to generate that
header by a shell script run at configure time.

Regards, Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-04 19:05 ` Andreas Rottmann
@ 2003-03-04 19:53   ` Rob Browning
  2003-03-05  0:55   ` Rob Browning
  1 sibling, 0 replies; 12+ messages in thread
From: Rob Browning @ 2003-03-04 19:53 UTC (permalink / raw)
  Cc: guile-devel

Andreas Rottmann <a.rottmann@gmx.at> writes:

> If you take a look at how other libraries, (e.g. GLib) do this, you'll
> see that most of them that need a public-installed, platform-specific
> header, use autoconf's AC_CONFIG_COMMANDS macro to generate that
> header by a shell script run at configure time.

OK, thanks.  I looked at what they to, and that might work.  I suppose
we'd use the respective $ac_cv_ vars to build the file.  Perhaps I'll
try to hack up a quick example as a test...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-04 19:05 ` Andreas Rottmann
  2003-03-04 19:53   ` Rob Browning
@ 2003-03-05  0:55   ` Rob Browning
  2003-03-13 19:45     ` Rob Browning
  1 sibling, 1 reply; 12+ messages in thread
From: Rob Browning @ 2003-03-05  0:55 UTC (permalink / raw)
  Cc: guile-devel

Andreas Rottmann <a.rottmann@gmx.at> writes:

> If you take a look at how other libraries, (e.g. GLib) do this, you'll
> see that most of them that need a public-installed, platform-specific
> header, use autoconf's AC_CONFIG_COMMANDS macro to generate that
> header by a shell script run at configure time.

My initial trial code seems reasonably promising, but this approach
does introduce the limitation that (without special precautions) we
can't use AC_DEFINE(GUILE_DEBUG ...) *and* expect to use GUILE_DEBUG
in our public header -- the two definitions, the one in config.h and
the one in libguile/scmconfig.h, would conflict.

The solution I'm leaning toward is to just remove the AC_DEFINEs for
any values we want to make public.  That's probably OK since we have
to duplicate the AC_DEFINE information in the AC_CONFIG_COMMANDS when
generating scmconfig.h anyway.  However, this does mean that if there
are any symbols that configure.in automatically AC_DEFINEs that we
also want to make public, we'll have to choose another name for the
public incarnation.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-04 19:04 What to do about config.h, etc Rob Browning
  2003-03-04 19:05 ` Andreas Rottmann
@ 2003-03-05 14:18 ` Marius Vollmer
  2003-03-06 22:04 ` Kevin Ryde
  2 siblings, 0 replies; 12+ messages in thread
From: Marius Vollmer @ 2003-03-05 14:18 UTC (permalink / raw)
  Cc: guile-devel

Rob Browning <rlb@defaultvalue.org> writes:

>   - Use a C program to translate from config.h to the public and
>     private headers,

I like this approach best, with a slight variation: only generate the
public header this way and let autoconf produce the private header.

The public header then does not need all the comments etc it just
needs to be functionally correct.  We would have duplicate symbols
(modulo the SCM_ prefix) in the public and private headers, but that
should be no problem.

Using a C program instead of a shell script makes supporting cross
compiling a little bit hairier, but not at all difficult, I'd say.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-04 19:04 What to do about config.h, etc Rob Browning
  2003-03-04 19:05 ` Andreas Rottmann
  2003-03-05 14:18 ` Marius Vollmer
@ 2003-03-06 22:04 ` Kevin Ryde
  2003-03-07  5:25   ` Rob Browning
  2 siblings, 1 reply; 12+ messages in thread
From: Kevin Ryde @ 2003-03-06 22:04 UTC (permalink / raw)


Rob Browning <rlb@defaultvalue.org> writes:
>
> Thoughts?  Better alternatives?

Another possibility is to manually create a template (or just the top
of some header file) into which settings are AC_SUBST-ed.  Quite nice
if there's not too many settings and they're kept on a fairly tight
rein.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-06 22:04 ` Kevin Ryde
@ 2003-03-07  5:25   ` Rob Browning
  2003-03-11 23:18     ` Kevin Ryde
  0 siblings, 1 reply; 12+ messages in thread
From: Rob Browning @ 2003-03-07  5:25 UTC (permalink / raw)
  Cc: guile-devel

Kevin Ryde <user42@zip.com.au> writes:

> Another possibility is to manually create a template (or just the top
> of some header file) into which settings are AC_SUBST-ed.  Quite nice
> if there's not too many settings and they're kept on a fairly tight
> rein.

True, though I've had some unpleasantness in the past with getting
AC_SUBST to expand things fully when I wanted it to (i.e. ${prefix}).
I'll keep that in mind though if the current approach doesn't work
out.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-07  5:25   ` Rob Browning
@ 2003-03-11 23:18     ` Kevin Ryde
  2003-03-12  3:12       ` Rob Browning
  0 siblings, 1 reply; 12+ messages in thread
From: Kevin Ryde @ 2003-03-11 23:18 UTC (permalink / raw)


Rob Browning <rlb@defaultvalue.org> writes:
>
> True, though I've had some unpleasantness in the past with getting
> AC_SUBST to expand things fully when I wanted it to (i.e. ${prefix}).

$prefix is pesky, the gnu rule is to expand it at "make" time, not
configure time, if I understand it correctly.

Nosing around libguile/Makefile.am, I wonder if @prefix@ in the
libpath.h setup should be $(prefix).  Perhaps the other @foo@'s
similarly (though they're substituted to ${prefix}/something, so end
up obeying a make-time prefix at least).

Mind you personally I think anyone who configures with one prefix and
makes with another is probably asking for trouble, in general.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-11 23:18     ` Kevin Ryde
@ 2003-03-12  3:12       ` Rob Browning
  0 siblings, 0 replies; 12+ messages in thread
From: Rob Browning @ 2003-03-12  3:12 UTC (permalink / raw)
  Cc: guile-devel

Kevin Ryde <user42@zip.com.au> writes:

> $prefix is pesky, the gnu rule is to expand it at "make" time, not
> configure time, if I understand it correctly.
>
> Nosing around libguile/Makefile.am, I wonder if @prefix@ in the
> libpath.h setup should be $(prefix).  Perhaps the other @foo@'s
> similarly (though they're substituted to ${prefix}/something, so end
> up obeying a make-time prefix at least).

Hmm I'll check on that.

> Mind you personally I think anyone who configures with one prefix and
> makes with another is probably asking for trouble, in general.

Well the main thing we need is the ability to install to a prefix
different from that used at configure time.  This is required by some
of the packaging systems.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-05  0:55   ` Rob Browning
@ 2003-03-13 19:45     ` Rob Browning
  2003-03-14 23:16       ` Kevin Ryde
  2003-03-14 23:28       ` Kevin Ryde
  0 siblings, 2 replies; 12+ messages in thread
From: Rob Browning @ 2003-03-13 19:45 UTC (permalink / raw)
  Cc: guile-devel

Rob Browning <rlb@defaultvalue.org> writes:

> My initial trial code seems reasonably promising, but this approach
> does introduce the limitation that (without special precautions) we
> can't use AC_DEFINE(GUILE_DEBUG ...) *and* expect to use GUILE_DEBUG
> in our public header -- the two definitions, the one in config.h and
> the one in libguile/scmconfig.h, would conflict.
>
> The solution I'm leaning toward is to just remove the AC_DEFINEs for
> any values we want to make public.  That's probably OK since we have
> to duplicate the AC_DEFINE information in the AC_CONFIG_COMMANDS when
> generating scmconfig.h anyway.  However, this does mean that if there
> are any symbols that configure.in automatically AC_DEFINEs that we
> also want to make public, we'll have to choose another name for the
> public incarnation.

After playing with the AC_CONFIG_COMMANDS approach for a while, I
think I may have to revert to my "generate the public header via a
small C program at build time" approach.  Though the
AC_CONFIG_COMMANDS approach *almost* works, I don't see any way to
handle things like TIME_WITH_SYS_TIME which autoconf automatically
AC_DEFINES when appropriate.  In this case, configure AC_DEFINEs this
value during the processing of AC_HEADER_TIME, and we require that
value, if any, in libguile/stime.h.  i.e. I need to be able to

  #define SCM_TIME_WITH_SYS_TIME 1

when appropriate, but AFAICT there's no way from configure.in to get
access to the value of something that is only AC_DEFINEd.  Note that
TIME_WITH_SYS_TIME isn't the only case, this will be true for any
other implicit AC_DEFINEs.

With the small C program approach, this isn't an issue because we have
direct access to the generated content of config.h via #include.

Suggestions and alternatives welcome...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-13 19:45     ` Rob Browning
@ 2003-03-14 23:16       ` Kevin Ryde
  2003-03-14 23:28       ` Kevin Ryde
  1 sibling, 0 replies; 12+ messages in thread
From: Kevin Ryde @ 2003-03-14 23:16 UTC (permalink / raw)


Rob Browning <rlb@defaultvalue.org> writes:
>
> After playing with the AC_CONFIG_COMMANDS approach for a while, I
> think I may have to revert to my "generate the public header via a
> small C program at build time" approach.

One approach to prefixing everything in config.h is

  http://www.gnu.org/software/ac-archive/htmldoc/ac_prefix_config_h.html

Seems slightly excessive to me, since public headers probably need
relatively little of a typical config.h.  But covering the whole thing
makes life easier I guess.

> AFAICT there's no way from configure.in to get
> access to the value of something that is only AC_DEFINEd.

Not unless it's also in a cache variable or something.  In the case of
AC_HEADER_TIME that's $ac_cv_header_time.  (Not sure if that variable
is actually documented.  It follows the _cv_ convention though, so
ought to be reasonably stable.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: What to do about config.h, etc...
  2003-03-13 19:45     ` Rob Browning
  2003-03-14 23:16       ` Kevin Ryde
@ 2003-03-14 23:28       ` Kevin Ryde
  1 sibling, 0 replies; 12+ messages in thread
From: Kevin Ryde @ 2003-03-14 23:28 UTC (permalink / raw)


Rob Browning <rlb@defaultvalue.org> writes:
>
> libguile/stime.h

Apropos of this file, it might be nice if SCM_TIME_UNITS_PER_SECOND
used sysconf(_SC_CLK_TCK) when that function is available.  That'd
ensure it gets the right answer if someone has tinkered with their
tick rate.  Perhaps make SCM_TIME_UNITS_PER_SECOND a global variable
initialized at program startup.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2003-03-14 23:28 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-04 19:04 What to do about config.h, etc Rob Browning
2003-03-04 19:05 ` Andreas Rottmann
2003-03-04 19:53   ` Rob Browning
2003-03-05  0:55   ` Rob Browning
2003-03-13 19:45     ` Rob Browning
2003-03-14 23:16       ` Kevin Ryde
2003-03-14 23:28       ` Kevin Ryde
2003-03-05 14:18 ` Marius Vollmer
2003-03-06 22:04 ` Kevin Ryde
2003-03-07  5:25   ` Rob Browning
2003-03-11 23:18     ` Kevin Ryde
2003-03-12  3:12       ` Rob Browning

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).