[Gc]: Maintainers attention: libatomic_ops

Petter Urkedal urkedal at nbi.dk
Wed Oct 7 00:17:18 PDT 2009


On 2009-10-07, Boehm, Hans wrote:
> I have to confess that I'm confused about the status (a common problem for me when dealing with autotools).  Things more or less seem to work for me, though I'm still getting warnings and huge diffs during and after rerunning the autotools.  Can someone summarize the recommended reconfiguration procedure?

I guess the warning you are seeing is from libtoolize which nags us
about declaring "AC_CONFIG_MACRO_DIR([m4])"?  See the first patch in
http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3379

About the reconfiguration procedure, I have used "autoreconf -vif" for
the last couple of years.  The autogen.sh file can us more control of
which version to use, though.

> My understanding is still that the only way we can avoid both complete standardization of reconfiguration procedure and large diffs is to remove things like Makefile.in and configure from cvs, which means that anyone wanting to build from cvs needs a complete set of autotools? 

My experience maintaining a hash-consing patch is that generated files
will create spurious conflicts on each merge/rebase, though I found a
way to deal with it (by using an intermediate cleanup-branch).

On the other hand, I can't think of a good way to distribute these files
to people who want to try out the bleeding edge sources.

> Especially since gcc apparently still checks in those files, and we've had too few releases recently, I'd still be inclined to leave build-essential files for now, if we can make it work tolerably.

I think you need to agree on very precise version of all the Autotools.
There must be people who have experience with this, since I know many
projects checks in generated files to the repo, including gcc as you
noted.


More information about the Gc mailing list