Re: Summary of config.h variables and questions.

[Rob Browning]

Marius Vollmer <address@hidden> writes:

>>   DYNAMIC_LINKING

So how should --with-modules (and its attendant settings) be handled?

>>   STACK_DIRECTION

For this one, we're not defining it, so I'm guessing we shouldn't make
it public.  This is defined by the built-in autoconf alloca function
check.  People should be using (and probably were unless they just
looked around in our scmconfig.h file) SCM_STACK_GROWS_UP.  So I'd be
tempted to just leave this one private.

Oh, and just so I'm clear, what was your opinion about all the other
"undecided" symbols?  If you didn't mention them, then does that mean
you think they should be published, prefixed with SCM_ or perhaps
something else?  They all have to be public in some way since we use
them in our headers.

I'll guess I'll change const to SCM_CONST and inline to SCM_INLINE or
similar along with all our public uses[1], but what about the rest
(i.e. DEBUG_EXTENSIONS -- which used to be public, but was deprecated,
HAVE_ARRAYS, etc.)?

[1] or do we just want to insist we have const?

Also, with the approach we're using, generating the public header from
configure.in, I can only make things public where we can get access to
the configure determined value.  So far that's been everything we've
cared about, but I thought I'd mention the limitation.  If something
is only AC_DEFINEd by configure.in macros that we don't have access
to, and there was no provision to add our own configure.in IF-TRUE,
IF-FALSE code, then we might be stuck.

-- 
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