Re: [Gc]: Dependency tracking for configuration macros
ivmai at mail.ru
Wed Sep 30 01:51:38 PDT 2009
Petter Urkedal <urkedal at nbi.dk> wrote:
> On 2009-09-29, Ivan Maidanski wrote:
> > Could you re-post the patch in this ML (if you think it should be applied to bdwgc)?
> Attached is the patch, excluding generated files. Log:
> * configure.ac: Rewrite the tests for external or internal
> * configure.ac: In particular, drop the symbolic links. Add option
> --with-libatomic-ops for forced selection.
> * Makefile.am: Adjust the path of source files from libatomic_ops to
> not use the links.
> * Makefile.am (libgc_la_LIBADD): Add $(ATOMIC_OPS_LIBS). This will be
> empty if we use the bundled AO sources.
Checked in the patch (with regenerate). Linux on FAT now works.
Before running autoreconf -vif, I deleted all .m4 files. Am I doing the right thing?
If yes, this is a bit compilated, so should we remove these files from GC (if they are used only during regeneration)?
If not, should config.h.in really contain undef GC version macros?
> > Nonetheless, I've committed the rename. I don't think having such an artifact is good - the hard-coded version, e.g., may make someone think bdwgc can work only with a particular libatomic_ops version. The cvs version numbers start from 1.1 but the old numbers and log history is in the old place - the only inconvenience is diff across rename (same as for libatomic_ops-1.1 to libatomic_ops-1.2 rename).
> Good. I agree it wouldn't have been nice. (BTW, Git, which I use,
> preserves the history across the rename. The reason is that it does not
> rely on metadata to detect moves but deduce it from the content of the
More information about the Gc