[Gc] bogus installed gc_config_macros.h

[Andy Wingo]

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/