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

Ivan Maidanski ivmai at mail.ru
Tue Sep 29 07:36:42 PDT 2009


Hi!

Petter Urkedal <urkedal at nbi.dk> worte:
> On 2009-09-25, Boehm, Hans wrote:
> > > From:  Ivan Maidanski
> > > I've deleted .m4 files and run autotools on Linux.
> > > 
> > > autoreconf works correctly but configure failed with error 
> > > "can't make a symbolic link" (that's because I've placed 
> > > "bdwgc" on NTFS drive) and make, then, failed too.
> > > Everything works correctly on a native Linux FS.
> > Same here.  Except I didn't try the NTFS case.
> > > 
> > > Should we fix this?
> > I'm with Petter on this.  If it's easy, great.
> 
> You can see my suggestion on the last two commits in
> 
>     http://git.eideticdew.org/cgit/~urkedal/bdwgc/log/?h=t-mv-ao
> 
> In involves a rewrite the libatomic_ops-related part of configure.ac,
> making it much simpler.

Could you re-post the patch in this ML (if you think it should be applied to bdwgc)?

> 
> As Ivan points out, CVS does not support moves, so this isn't straight
> forward to commit without loosing history.  An alternative may be to
> keep for version (as long as the project is under CVS), hard-code it
> into the build, and call it an artifact.
>  
> > If it involves getting rid of the version number from the atomic_ops directory, even better, since that was on my list anyway.  Libatomic_ops should either be handled as a separate package, or should just use GC version numbers.  And I think the former option requires more work for which we're currently lacking volunteers.

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).

> I think libatomic_ops is very useful on its own right.  Nevertheless,
> the choice of keeping it under the same SCM doesn't need to affect the
> end-user, since a packager is free to build the two separately.  (I made
> sure in the cited topic branch to maintain that option.)

Bye.


More information about the Gc mailing list