Re: What to do about config.h, etc...

[Rob Browning]

Rob Browning <address@hidden> 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