Re[2]: [Gc]: Dependency tracking for configuration macros

Ivan Maidanski ivmai at mail.ru
Wed Sep 30 01:51:38 PDT 2009


Hi!

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
> 	libatomic_ops.
> 	* 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
> files.)

Bye.


More information about the Gc mailing list