[Gc] Dependency tracking for configuration macros
urkedal at nbi.dk
Thu May 21 07:04:42 PDT 2009
On 2009-05-21, Ivan Maidanski wrote:
> 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
> 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
(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
> 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