[Gc]: Dependency tracking for configuration macros

Petter Urkedal urkedal at nbi.dk
Sat Sep 26 06:40:56 PDT 2009


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.

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.

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


More information about the Gc mailing list