[Gc] Dependency tracking for configuration macros

Petter Urkedal urkedal at nbi.dk
Thu May 21 09:23:39 PDT 2009


On 2009-05-21, Ivan Maidanski wrote:
> Petter Urkedal <urkedal at nbi.dk> wrote:
> > On 2009-05-21, Ivan Maidanski wrote:
> > > 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.
> 
> Miscommunicating a bit...
> The above code is for gc.h (or gc_config_macros.h) containing (as I understood what You suggest):
> 
> #if defined(I_HAVE_CUSTOM_GC_API_CONFIG)
> /* define it (before including gc.h or friends) if your app has this config file */
> #include "gc_api_config.h"
> #endif

If API depended on it, we'd probably want to manifest the configuration
as an installed header, independent of how the collector was built.

> As You wrote above "config.h-dependencies seems to be avoidable", the question is closed (again, if I understood that right).

Yes, case closed.

Petter


More information about the Gc mailing list