Re[2]: [Gc] bogus installed gc_config_macros.h

Ivan Maidanski ivmai at mail.ru
Fri Mar 15 13:15:42 PST 2013


 Hi Andy,

I see. Though I treat GC_THREADS defined before gc.h inclusion as a confirmation of intention rather than a code duplication, I agree that it could be convenient for some clients to specify GC parameters only once at GC build time and just include gc.h from their code. For this, we could add some configure option (e.g., --with-gc-config), so that it will generate additional gc_config.h (I'm not sure about the suitable names right now) which will record GC configuration tested by gc.h (and gc_config_macros.h) when client uses it provided the client use -DHAVE_GC_CONFIG_H. gc_config_macros.h is left as-is.

Do you accept this idea and could propose a patch adding such functionality?

Thank you.

Regards,
Ivan

Sun, 10 Mar 2013, 19:08 +01:00 from Andy Wingo <wingo at pobox.com>:
>Hi Ivan,
>
>On Sun 10 Mar 2013 07:18, Ivan Maidanski < ivmai at mail.ru > writes:
>
>> CFLAGS=-DGC_WIN32_PTHREADS at client code compilation should solve the
>> problem.
>
>It does, yes.
>
>> --enable-threads=pthreads at GC build time influences only which API to
>> use for marker threads creation and whether GC_pthread_X functions are
>> defined (i.e., GC_CreateThread and friends are defined in either case).
>
>I see, thank you.
>
>>     easiest way is probably to just move gc_config_macros.h to
>>     gc_config_macros.h.in, and have AC_OUTPUT_FILES substitute in the
>>     correct choices.
>>
>> Currently, both gc and atomic_ops public API does not force the clients
>> to run configure stuff. I don't think it's worth breaking this principle
>> just because of mingw+pthread-win32 target (having
>> CFLAGS=-DGC_WIN32_PTHREADS workaround for it).
>> Are there other solutions?
>
>I'm not sure if I expressed myself well.  I guess my point is, when you
>configure bdw-gc, you select a configuration (most importantly, with
>threads or without).  This decision is visible to users of bdw-gc.  It
>would be nice if users didn't have to repeat themselves (e.g. by
>defining GC_THREADS (and possibly also GC_WIN32_PTHREADS) before
>#include <gc/gc.h>), because this choice was already made.  Of course
>you can initialize the collector without threads if you compiled with
>threads, but that doesn't affect the interface (API/ABI) that bdw-gc was
>configured to provide.
>
>I have worked around this issue in Guile for the mingw case, so I guess
>there is no urgent bug.  But I still think it could be useful to
>install a gc_config_macros.h that records the choices made at bdw-gc
>compilation time, instead of the choices made when the user code
>includes the bdw-gc headers.
>
>Cheers,
>
>Andy
>-- 
>http://wingolog.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130316/f8e9dffd/attachment.htm


More information about the Gc mailing list