From: Jeff Garzik <jeff@garzik.org>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: Jim Meyering <jim@meyering.net>, hail-devel@vger.kernel.org
Subject: Re: AC_CONFIG_MACRO_DIR([m4])
Date: Mon, 06 Dec 2010 12:32:22 -0500 [thread overview]
Message-ID: <4CFD1E26.8010908@garzik.org> (raw)
In-Reply-To: <20101205145655.4f91e5d6@lembas.zaitcev.lan>
On 12/05/2010 04:56 PM, Pete Zaitcev wrote:
> Autoconf printed a warning when reconfiguting Hail, so I gave up and
> added this:
[...]
> Now I have a directory m4/ with symlinks... This does not seem to be
> helping any portability, unless I miss where the promised macro are
> being saved locally. What was this about, do you happen to know?
I presume you refer to this:
> [jgarzik@bd hail]$ ./autogen.sh && CFLAGS="-O2 -Wall -Wshadow -g -march=native" ./configure --disable-shared
> libtoolize: putting auxiliary files in `.'.
> libtoolize: linking file `./ltmain.sh'
> libtoolize: You should add the contents of the following files to `aclocal.m4':
> libtoolize: `/usr/share/aclocal/libtool.m4'
> libtoolize: `/usr/share/aclocal/ltoptions.m4'
> libtoolize: `/usr/share/aclocal/ltversion.m4'
> libtoolize: `/usr/share/aclocal/lt~obsolete.m4'
> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> libtoolize: putting auxiliary files in `.'.
> libtoolize: linking file `./ltmain.sh'
> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Think about what this implies:
Keeping the "correct libtool macros in-tree" implies adding a pointless
maintenance burden. The distro always gives us correct, up-to-date
files. Why would hail want to potentially lag upstream's version of
these macros, forcing us to manually track macros that are currently
updated automatically for each ./autogen.sh invocation?
It is this same silly logic that leads programmers to ship in-tree
copies of (for example) zlib.
Therefore, the requirement to rebuild hail's configure script is to have
a recent distro.
Users of tarballs never see this, so this is only an issue for those on
oddball or ancient OS's, who are building release tarballs, or working
directly out the git repo.
And if someone is doing that, they have a lot more headaches than just
outdated libtool to contend with.
Jeff
next prev parent reply other threads:[~2010-12-06 17:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-05 21:56 AC_CONFIG_MACRO_DIR([m4]) Pete Zaitcev
2010-12-06 11:12 ` AC_CONFIG_MACRO_DIR([m4]) Jim Meyering
2010-12-06 17:32 ` Jeff Garzik [this message]
2010-12-06 17:44 ` AC_CONFIG_MACRO_DIR([m4]) Pete Zaitcev
2010-12-06 18:56 ` AC_CONFIG_MACRO_DIR([m4]) Jeff Garzik
2010-12-06 19:26 ` AC_CONFIG_MACRO_DIR([m4]) Jim Meyering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CFD1E26.8010908@garzik.org \
--to=jeff@garzik.org \
--cc=hail-devel@vger.kernel.org \
--cc=jim@meyering.net \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.