Re: AC_CONFIG_MACRO_DIR([m4])
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 - -- To unsubscribe from this list: send the line unsubscribe hail-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AC_CONFIG_MACRO_DIR([m4])
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: [jgar...@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 -- To unsubscribe from this list: send the line unsubscribe hail-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AC_CONFIG_MACRO_DIR([m4])
On 12/06/2010 12:44 PM, Pete Zaitcev wrote: On Mon, 06 Dec 2010 12:32:22 -0500 Jeff Garzikj...@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 -- To unsubscribe from this list: send the line unsubscribe hail-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AC_CONFIG_MACRO_DIR([m4])
Jeff Garzik wrote: On 12/06/2010 12:44 PM, Pete Zaitcev wrote: On Mon, 06 Dec 2010 12:32:22 -0500 Jeff Garzikj...@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. -- To unsubscribe from this list: send the line unsubscribe hail-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
