[Gc]: Maintainers attention: libatomic_ops

Matthias Andree matthias.andree at gmx.de
Wed Oct 7 02:45:40 PDT 2009

Am 07.10.2009, 07:19 Uhr, schrieb Boehm, Hans <hans.boehm at hp.com>:

> 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?

Warnings that do *not* stem from packages that install .m4 files  
themselves can be fixed by maintainers or contributors with commit  
permissions, usually through minor changes to Makefile.am/configure.ac  

Warnings that *do* come from packages that installe .m4 files, or more  
precisely, from these .m4 files, can only be fixed by the maintainers of  
these packages; libtool and gettext are candidates here.

Warnings about suspicious names or cache-ids (lacking _cv_ and hence  
uncached) are not a functional problem, but just state that these  
variables are no longer cached in config.cache (when they were in autoconf  
2.13). Note that the cache is only saved if you run ./configure with -C  

Huge diffs stem from a model that commits generated files to CVS, which is  
a practice I personally discourage, but that every project manager has to  
decide for his projects.

The canonical autotools reconfiguration procedure is "autoreconf" and only  
"autoreconf", perhaps with a set of options (I am oblivious of the long  

-i (install missing files, usually on the first run after checkout)
-s (use symlinks instead of copies)
-f (force overwriting)
-v (verbose mode)
-Wall (in newer versions only, propagates to the individual tools where it  
enables warnings)

> 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?

Yes. That is a common expectation and easy on the users, as all halfway  
recent and supported distributions ship adequate versions of autotools.

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

Depends on who rolls the release or snapshot tarballs, and how.
The canonical way for all autotools based projects is to use "make  


Matthias Andree

More information about the Gc mailing list