[Gc] libatomic_ops: time to alpha release?
urkedal at nbi.dk
Thu Oct 15 09:38:44 PDT 2009
On 2009-10-14, Boehm, Hans wrote:
> I seem to be able to build everything again, sort of, after a
> rm /usr/share/aclocal/librapi2.m4
> (actually, I did back it up somewhere)
> It seems to be the case that if some ancient package drops something into /usr/share/aclocal and then doesn't get updated, autotools break?
Yes, that can happen. aclocal needs to scan all the files because it
does not know which file contains the macro it's looking for. It would
be better if they could enforce the convention that each file contains a
macro of exactly the same name in uppercase (or by extension a set of
macros which starts with the same prefix). Then aclocal could pick it
> More importantly, it also seems I still need to move libtool.m4 out of the way to reconfigure, which I think is unacceptable. It seems like Petter's patch from https://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3379
> fixes that. Is there a reason not to commit it? If I understand correctly, this forces us to permanently remove libtool.m4, create an m4 subdirectory, and presumably check the generated contents of that into the tree, so that libtool is again part of the tree. That's a minor annoyance, but seems OK, since it seems to be the new improved way of doing things. Does this sound right?
I don't think we need to commit the files under m4 to the repo, since
they are not used by configure. The only benefit I can see of
committing them is for someone who has all Autotools except Libtool.
So, to minimise the number of generated files in the repo, my suggestion
is to cvsignore them instead.
More information about the Gc