Re[2]: [Gc]: Maintainers attention: libatomic_ops

Ivan Maidanski ivmai at mail.ru
Thu Oct 1 23:33:36 PDT 2009


Hi!

Petter Urkedal <urkedal at nbi.dk> wrote:
> > > > > On 2009-10-01, Ivan Maidanski wrote:
> > > > > > Ok. I've installed it, deleted libtool.m4 and run autoreconf -vif. It prints:
> > > > > >
> > > > > > libtoolize: You should add the contents of the following files to `aclocal.m4':
> > > > > > libtoolize:   `/usr/local/share/aclocal/libtool.m4'
> > > > > > libtoolize:   `/usr/local/share/aclocal/ltoptions.m4'
> > > > > > libtoolize:   `/usr/local/share/aclocal/ltversion.m4'
> > > > > > libtoolize:   `/usr/local/share/aclocal/ltsugar.m4'
> > > > > > libtoolize:   `/usr/local/share/aclocal/lt~obsolete.m4'
> > > > > >
> > > > > > What does this mean?

I've checked in this one (which prints these warnings). I'd typed (to regenerate):

mv libtool.m4 libtool.m4.hidden
autoreconf -vif
mv libtool.m4.hidden libtool.m4
rm -r autom4te.cache libatomic_ops/autom4te.cache

If this satisfies most parties, I don't want to apply any of these 2 patches because I don't want to type more "rm" or "cp" (or have my local tree different from CVS or upcoming tar-ball ones).

Hans -
if you have a strong opinion on the two discussed patches (http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3379), let us know.

> > > > >
> > > > > aclocal.m4 is a collection of macros which goes into configure.ac.  It
> > > > > includes acinclude.m4 and picks up from /usr/share/aclocal and any -I
> > > > > options passed to aclocal those macros which occurs in configure.ac.  I
> > > > > don't know exactly why libtoolize asks you to do this, because it should
> > > > > be done automatically by aclocal, but I think it'll be happy if we
> > > > > declare AC_CONFIG_MACRO_DIR.  See the attached patch.  libtoolize should
> > > > > now put the m4 files into the m4 subdirectory, but I suggest not to
> > > > > commit them to the repo.
> > > > >
> > > > > We could also tidy the top-level directory by declaring
> > > > > AC_CONFIG_AUX_DIR as in the second patch.  Note that the files compile,
> > > > > config.guess, config.sub, install-sh, and missing should then be removed
> > > > > from the top dir and the files in build-aux/ committed instead.
> > > >
> > > > Complicated regeneration...
> > > >
> > > > I don't understand - which of two patches should be applied you think (or both, or none)?
> > >
> > > The first one will silence libtoolize.  I think they're just warnings;
> > > you can check if configure, ltmain.sh and the other files has been
> > > updated.
> >
> > I don't think this patch worth applying as it complicates regeneration (you say: libtoolize should now put the m4 files into the m4 subdirectory, but I suggest not to commit them to the repo.)
>
> Ah, that's what you meant by "complicated regeneration...".  I think
> there is a point to the extra copying, namely that these m4 files makes
> it into the tarball.  That could benefit someone applies a patch to the
> tarball, and who have the auto* tools, but not libtool.
>
> > > The second patch is completely optional, and helps reduce the noise in
> > > the top-level directory.
> >
> > I don't like it neither (for the same reason).
>
> The AC_CONFIG_AUX_DIR will not cause any extra copying.  The same files
> will be copied either to the project's top-level directory or to the
> declared sub-directory.


More information about the Gc mailing list