GNOME Bugzilla – Bug 160943
add AC_CONFIG_MACRO_DIR() support to intltoolize
Last modified: 2005-01-21 02:51:32 UTC
One of the consta nt problems people run into with autotools is mismatching an M4 macro with the other support files required by a build tool. This often happens when the path aclocal is using to look up macros differs from $PATH, which can cause problems when multiple versions of the build tool are on the system. From what I can tell, this is the cause of bug 154382, and probably others. The way this is being solved in tools like libtool is to make the XXXize script install the macros itself, so that aclocal doesn't need to find it. The way this works is by checking if the AC_CONFIG_MACRO_DIR() macro is used in configure.in, and if so copy the macro there. So if a package is modified to use AC_CONFIG_MACRO_DIR(), it gets the robustness benefits, but the old behaviour is preserved for existing packages that don't use the macro. The attached patch adds support for this scheme to intltoolize.
Created attachment 34696 [details] [review] intltool-macrodir.patch
Well, the mismatched versions is certainly why people get the @INTLTOOL_FOO error. However, it is caused by a broken environment. I don't see how this is going to solve the problem, since nobody uses AC_CONFIG_MACRO_DIR afaik. It might fix it for one or two packages, but unless you go make every package use AC_CONFIG_MACRO_DIR, which seems silly to me, this doesn't really solve anything. aclocal still has to find the macros. It's just a matter of specifying a local dir to look in, and I'm not sure that still solves the problem really.
Making it possible for a maintainer to make their package's build infrastructure more robust doesn't seem useless to me. This is a feature that is also found in the libtool-2.0 betas, and will likely become common in all the GNU build tools.
I agree with James here: fixing this progressively (even if slowly) is better than just don't caring about it.
I wasn't saying that I don't care about it. I'm saying that it's usefulness is based on whether or not people will use it, and given how people already hate autotools a lot, I don't think they are going to be readily willing to have to copy a bunch of macros into the srcdir in order to build from CVS. If I'm going to add this, then people should use it, but I don't want to put it in if nobody is going to use it. So maybe we should get at least the gnome platform libs to do the AC_CONFIG_MACRO_DIR thing. Also, I hope that it actually works and doesn't dist the directory, or bitch if the directory doesn't exist. That'll probably bother some people. I don't think it's a useless feature. I just think it's one that would go unused.
Remember that in the current setup, the required macros already get copied to the source directory -- they are just concatenated together with acinclude.m4 to create the aclocal.m4 file. If a package uses AC_CONFIG_MACRO_DIR(), then the only real difference is that the macros are in separate files. The "aclocal" utility is smart enough to not copy them into aclocal.m4, and instead adds a reference to them like this: m4_include([m4/foobar.m4]) Automake >= 1.8 is smart enough to automatically distribute referenced macros, so it doesn't add any extra burden to maintainers. If you want an example of a package using AC_CONFIG_MACRO_DIR, take a look at libglade. It'll pull in the gtk-doc macros when autogen.sh is run (and will pull in the libtool macros once 2.0 is released). I then listed these external files in m4/.cvsignore so they don't accidentally get added to CVS. I suppose I could look at getting a package using intltool converted if that would help.
Hrmm. If it's just doing m4_include() is there any way we can skip the whole copying bit and just add an m4_include() somewhere that has the full path? I would like that much better... assuming that it actually gets the right stuff shoved in the resulting configure script, and not just the m4_include() call. I think I'll commit this as-is for now though, after I look through it again. I don't really feel like arguing it too much. I just think it is sub-optimal and very few people will actually use the feature.
Thanks for checking this in. The reason for including the m4 files in the tarball is so that the configure script can be regenerated even if the macros aren't available on the system (distributors sometimes need to do this). Having m4_include() directives pointing outside of the source tree would make things more difficult than the current setup (eg. not many people have a /home/james/prefix/share/aclocal/intltool.m4 on their system), which is why I suspect they don't do it that way.