AC_CONFIG_MACRO_DIR([m4])

AC_CONFIG_MACRO_DIR([m4])

[Pete Zaitcev]

Hi, Jim:

Autoconf printed a warning when reconfiguting Hail, so I gave up and
added this:

diff --git a/configure.ac b/configure.ac
index 9cfad23..d378854 100644
--- a/configure.ac
+++ b/configure.ac
@@ -62,6 +62,8 @@ AC_PROG_GCC_TRADITIONAL
 AM_PROG_CC_C_O
 AM_PROG_LIBTOOL
 
+AC_CONFIG_MACRO_DIR([m4])
+
 dnl Checks for header files.
 AC_HEADER_STDC
 dnl AC_CHECK_HEADERS(sys/ioctl.h unistd.h)

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?

-- Pete

Re: AC_CONFIG_MACRO_DIR([m4])

[Jim Meyering]

Pete Zaitcev wrote:
> Hi, Jim:
>
> Autoconf printed a warning when reconfiguting Hail, so I gave up and
> added this:
>
> diff --git a/configure.ac b/configure.ac
> index 9cfad23..d378854 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -62,6 +62,8 @@ AC_PROG_GCC_TRADITIONAL
>  AM_PROG_CC_C_O
>  AM_PROG_LIBTOOL
>
> +AC_CONFIG_MACRO_DIR([m4])
> +
>  dnl Checks for header files.
>  AC_HEADER_STDC
>  dnl AC_CHECK_HEADERS(sys/ioctl.h unistd.h)
>
> 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?

Hi Pete,

The symlinks are ok, since "make dist" dereferences them
when creating a tarball.  However, if for some reason you find
a problem due to the use of symlinks (in that case, please
let us know -- who knows, might have to change the default) you
can add --copy (-c) to the libtoolize invocation in autogen.sh.

You'll also want the following patch, so that aclocal
knows where to find the .m4 files:

diff --git a/Makefile.am b/Makefile.am
index 38a1d92..e5bf438 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,7 +2,8 @@
 ## Toplevel Makefile.am
 ##

+ACLOCAL_AMFLAGS = -I m4
+
 SUBDIRS		= doc lib include cld chunkd tools test

 EXTRA_DIST	= autogen.sh Doxyfile COPYING LICENSE
-

Re: AC_CONFIG_MACRO_DIR([m4])

[Jeff Garzik]

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

Re: AC_CONFIG_MACRO_DIR([m4])

[Pete Zaitcev]

On Mon, 06 Dec 2010 12:32:22 -0500
Jeff Garzik <jeff@garzik.org> wrote:

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

I presumed that the important part is a compatibility between the
syntax used in various .am files and the libtool scriptography that
underpins them. "Lagging" upstream has no downside in this case
(unlike zlib, where security fixes may exist).

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

Well, if you say so...

-- Pete

Re: AC_CONFIG_MACRO_DIR([m4])

[Jeff Garzik]

On 12/06/2010 12:44 PM, Pete Zaitcev wrote:
> On Mon, 06 Dec 2010 12:32:22 -0500
> Jeff Garzik<jeff@garzik.org>  wrote:
>
>> 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?
>
> I presumed that the important part is a compatibility between the
> syntax used in various .am files and the libtool scriptography that
> underpins them. "Lagging" upstream has no downside in this case
> (unlike zlib, where security fixes may exist).

It does not seem optimal to run a current libtool with outdated macro 
files.  In all cases except current one, you're checking in third party, 
maintained, versioned files to hail.git where they will be less-well 
maintained, and generally out-of-date vis a vis current [upstream | Fedora].

Where is the value in performing this additional work, besides silencing 
a warning seen only by git repo users?


>> 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.
>
> Well, if you say so...

Do you have knowledge to the contrary?

	Jeff

Re: AC_CONFIG_MACRO_DIR([m4])

[Jim Meyering]

Jeff Garzik wrote:
> On 12/06/2010 12:44 PM, Pete Zaitcev wrote:
>> On Mon, 06 Dec 2010 12:32:22 -0500
>> Jeff Garzik<jeff@garzik.org>  wrote:
>>
>>> 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?
>>
>> I presumed that the important part is a compatibility between the
>> syntax used in various .am files and the libtool scriptography that
>> underpins them. "Lagging" upstream has no downside in this case
>> (unlike zlib, where security fixes may exist).
>
> It does not seem optimal to run a current libtool with outdated macro
> files.  In all cases except current one, you're checking in third
> party, maintained, versioned files to hail.git where they will be
> less-well maintained, and generally out-of-date vis a vis current
> [upstream | Fedora].

Hi Jeff,

The patch that adds those two lines does not (and IMHO should not)
imply that a project would version-control those files.
Typically, those symlinks exist only in your working directory,
and not in any project's VC repository.

If you have no other files in m4/, you can simply .gitignore
the entire m4/ directory.

> Where is the value in performing this additional work, besides
> silencing a warning seen only by git repo users?

Yeah, either way it's not a big deal.