Re: [Gc]: Dependency tracking for configuration macros
ivmai at mail.ru
Tue Sep 29 07:36:42 PDT 2009
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
> 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.)
More information about the Gc