[Gc] Dependency tracking for configuration macros

Petter Urkedal urkedal at nbi.dk
Thu May 21 07:04:42 PDT 2009

On 2009-05-21, Ivan Maidanski wrote:
> Hi!
> Petter Urkedal <urkedal at nbi.dk> wrote:
> > On 2009-05-20, Ivan Maidanski wrote:
> > > 2. Inclusion of a "private/..." file from a public header ("gc_config_macros.h") is not a good idea (even if it is ifdef'ed), I think.
> > 
> > I principal I agree, but the problem is that "gc.h" includes
> > "gc_version.h", and the latter file must be included after the Autoconf
> > macros, if they are to be included.  This is the reason I felt it
> > necessary to add GC_PRIVATE_CONFIG_H as a supplement to the standard
> > CONFIG_H definition.  I consider the ifdef-guard safe since
> > GC_PRIVATE_CONFIG_H is in the "namespace" of the collector, but granted,
> > it looks a bit ugly to an end-user who reads the include file.
> Another way:
> 1. include "private/gc_priv.h" at the beginning of backgraph.c, checksums.c, gcj_mlc.c, real_malloc.c and gc_pmark.h;
> 2. include "gc_version.h" and configuration file (ifdef'ed) at the beginning of "gc_priv.h" (before including "gc.h").

I don't have a strong opinion here.  We avoid littering gc.h with the
conditional macro inclusion, but at the price of making the order of
inclusion significant.

> 3. I'd like also to see #define GC_BUILD (ifndef'ed) in gc_priv.h after config file included.
> What do You think?

Even though gc_priv.h and gc_pmark.h are private, there may be cases
where client code includes them, esp to customize the marking process
for specific runtime environments.  So, I'd leave this one for the build
to #define.

(A small refinement is to set "libgc_la_CFLAGS = -DGC_BUILD" in
Makefile.am, since the option applies exactly when building libgc.la.
The other builds must be adjusted analogously before we can get rid of
the #undef GC_BUILD in test.c.)

> > On a related note, it might also be of interest to make configuration
> > macros available from public headers.  In my own code I usually
> > transform the config.h by adding a project-specific prefix to all macros
> > which do not already start with said prefix.
> May be. But how many macros could be there? GC_THREADS, GC_DLL (Win32 only), GC_USE_LD_WRAP (Unix only), the rest are of rare use.

I probably shouldn't have brought this up.  The config.h macros can be
useful when inlined code or type definitions depend on system-specific
features or feature/tuning parameters decided by ./configure.  However,
the libgc public headers use system/compiler-specific predefined
constants rather than feature-tests.  Since also the main GC API has
little inlining and few datastructures, config.h-dependencies seems to
be avoidable.

> The other Q: are You going to make this 'public' config auto-gen'ed by GC too? Otherwise, it's not clear how this would be looking in the client code:
> #include "my_app_config.h"
> #define I_HAVE_CUSTOM_GC_API_CONFIG /* looks a bit ugly here */
> #include "gc.h"
> If we move "define I_HAVE_..."  to my_app_config then the Q: isn't that easy to just have "include my_gc_config.h" in it ("my_app_config.h") instead (or directly have "define GC_THREADS"... unless you have a standalone cfg script for the gc API in your app)?

I'm not sure whether I understood the question, but config.h should only
contain definitions which are decided once and for all by ./configure.
If there are feature-macros which the client can #define to tweak the
API, then they don't belong in config.h.


More information about the Gc mailing list