GNOME Bugzilla – Bug 323968
intltoolize fails with AC_CONFIG_AUX_DIR
Last modified: 2008-07-21 14:23:52 UTC
Please describe the problem: For a new appp I have my autools located in a subdirectory i. e., I have set AC_CONFIG_AUX_DIR in configure.in. When invoking intltoolize it fails with the message cp: cannot create regular file `po/Makefile.in.in': No such file or directory. This is nonsense, the all files which should exists are there with correct permission Steps to reproduce: 1. Set upp application with AC_CONFIG_AUX_DIR defined in configure.in 2. Run intltoolize 3. Watch crash (see above). Actual results: Crash Expected results: Files successfully copied Does this happen every time? Yes Other information: This is is related to the file po/Makefile.in.in - this is the only file with a directory specification. All other files are OK. A patch is under way.
Created attachment 55939 [details] [review] Patch resolving problem for me. Not tested without AC_CONFIG_AUX_DIR
Please submit patches in unified diff format. The recommended arguments to diff for CVS are -up.
Created attachment 55942 [details] [review] new patch in (hopefully) better shape.
There are more problems using AC_CONFIG_AUX_DIR: the file po/Makefile.in.in generated contains a reference to ../mkinstalldirs. Using AC_CONFIG_AUX_DIR this should be something like ../autotools/mkinstalldirs; autotolls is the subdirectory used for support files. Fixing embarrasing type in summary
Updating the summary to reference the problem correctly, and confirming. intltoolize doesn't crash, it simply fails.
Created attachment 65398 [details] [review] Proposed patch I also did a patch. It seems to work fine for me.
OK, I still don't understand the semantics of AC_CONFIG_AUX_DIR enough. Distcheck fails for me with the patch. It seems to be because the .in files that get placed in the auxdir now, aren't getting disted. And, I'm not sure what the proper way for them to be disted, is. As such, I'm going to leave this patch out for now. I think it needs more work still, and the current patch is just a bandaid for what a few people see.
So far I've seen this problem with ascal and gnubiff.
*** Bug 377991 has been marked as a duplicate of this bug. ***
I've seen this problem with d4x 2.5.7.1.
I'm going to reject the rest of these patches, and mark this bug as depending on #490620. That bug is requesting that we no longer ship intltool inside of source tarballs, and that we instead simply depend on the scripts that are installed in the system, at build time. There seems to be significant request from the community for this, and it makes sense to do it, so I will be implementing that before the 0.37 release. With that change, intltoolize will be reduced to /bin/true, for compatibility reasons with autogen scripts that will continue to run intltoolize. That will make these changes completely unneeded.
I seen this trying to use intltoolize with gnokii as well.
Hi, This bug is also present in the latest release 0.40. However, thanks to #490620, no files are added to AUX_DIR anymore (only Makefile.in.in is copied), so maybe you could just ignore AC_CONFIG_AUX_DIR entirely in /usr/bin/intltoolize.
(In reply to comment #13) > Hi, > > This bug is also present in the latest release 0.40. However, thanks to > #490620, no files are added to AUX_DIR anymore (only Makefile.in.in is copied), > so maybe you could just ignore AC_CONFIG_AUX_DIR entirely in > /usr/bin/intltoolize. > Correct. After reviewing the AC_CONFIG_AUX_DIR documentation, I've removed these checks from intltoolize, as we no longer copy any scripts locally. This is fixed in SVN now, and will be part of the pending 0.40.1 release.