GNOME Bugzilla – Bug 116362
intltool.m4 does not respect AC_CONFIG_AUX_DIR
Last modified: 2004-12-22 21:47:04 UTC
All intltool-*.in files are created in appropriate directory as defined by AC_CONFIG_AUX_DIR. However, the code in intltool.m4 expects to find intltool-*.in files in the 'top_builddir'.
Created attachment 18120 [details] [review] A proposed patch to fix this bug
Raising priority since patch is attached
Removing I18N keyword, this bug is not related to i18n issue.
Can this (rather old) patch get merged? I ran into this problem and it's basically a total show-stopper for the other folks trying to do CVS work with the autoconf files in my project. Thanks!
I don't know how I missed this one. Sorry. Kees does the patch still apply? If so please check in and mark this bug as fixed. If you don't I will do it later today (hopefully) Kenneth
I'm attaching a variation. It doesn't depend on automake, and applies cleanly to v0.28.
Created attachment 22403 [details] [review] Clean fix for auxdir (no automake). Made against 0.28
committed to cvs. Please check to see if it works for you. If not, reopen.
I think the patch cause problems on distcheck (of packages using intltool). It tries to create the .out in the src dir which is read only.
I'm pretty sure the patch that committed breaks distcheck. I'm attaching a minimal tarball, with autogen included, that shows the problem. steps to reproduce: a) jhbuild buildone intltoolize (to make sure intltool is updated) b) jhbuild shell (to make sure your environment is set up to pick up the right intltool.m4) c) unpack the tarball attached d) ./autogen.sh e) grep ^INTLTOOL_MERGE aclocal.m4 It should contain this line: INTLTOOL_MERGE="\$(top_builddir)/${ac_aux_dir}/intltool-merge" Which is due to the patch commited. (This step is to verify you have the right setup that triggers the bug) f) make distcheck This will have a few non-fatal errors due to wrong intltool tool locations, e.g. config.status: executing default-1 commands ./config.status: line 812: ../intltool-extract.out: Permission denied mv: cannot stat `../intltool-extract.out': No such file or directory chmod: failed to get attributes of `../intltool-extract': No such file or directory chmod: failed to get attributes of `../intltool-extract': No such file or directory ./config.status: line 821: ../intltool-merge.out: Permission denied and fail fatally with: LC_ALL=C ../../intltool-merge ../../po ../../desktop/intltool-merge-test.desktop.in intltool-merge-test.desktop -d -u -c ../po/.intltool-merge-cache /bin/sh: line 1: ../../intltool-merge: No existe el fichero o el directorio make[2]: *** [intltool-merge-test.desktop] Error 127 With the patch reverted, this sample tarball works fine. Kees, I'm not really sure what your patch is supposed to be fixing. Can you do something similar to me, ie make a similar bare tarball that exposes your problem ? That way I can cook up a fix that works for both tarballs. If I don't hear from this bug soon I'm going to revert because this patch breaks make distcheck on *a lot* of modules. Marco, thoughts ? Thanks
Created attachment 22769 [details] tarball showing the bug
Created attachment 22771 [details] [review] patch to revert the two latest patches to intltool
the attached patch reverts the previous patch from this bug report, as well as the patch in bug 129773. I'm pretty sure 129773 is caused by the patch higher up. Using this new patch to revert the two previous ones makes the test tarball pass make distcheck. Let me know, so I can fix the majority of gnome builds again.
Created attachment 22777 [details] Example with intltool 0.28 showing broken AUX_DIR behavior
If you run "autogen.sh" (you'll have to hit enter after the gettextize warning), you'll see several errors from intltool: The first is during intltoolize itself: + intltoolize --automake --copy --force /usr/bin/intltoolize: line 263: /home/kees/hi/example/mkinstalldirs: No such file or directory patching file po/Makefile.in.in (mkinstalldirs is in the AUX_DIR "autotools") The rest of the problems happen during the "config.status" run: ./config.status: line 1455: ./intltool-extract.in: No such file or directory mv: cannot stat `intltool-extract.out': No such file or directory chmod: failed to get attributes of `intltool-extract': No such file or directory chmod: failed to get attributes of `intltool-extract': No such file or directory ./config.status: line 1464: ./intltool-merge.in: No such file or directory mv: cannot stat `intltool-merge.out': No such file or directory chmod: failed to get attributes of `intltool-merge': No such file or directory chmod: failed to get attributes of `intltool-merge': No such file or directory ./config.status: line 1474: ./intltool-update.in: No such file or directory mv: cannot stat `intltool-update.out': No such file or directory chmod: failed to get attributes of `intltool-update': No such file or directory chmod: failed to get attributes of `intltool-update': No such file or directory
Kees, if you cannot find a way to make your applied patch work for Thomas and Marco I will let Thomas revert the patch. I will give you till tomorrow. Kenneth
<disclaimer>I dont have a real clue about auto* so get this with a grain of salt</disclaimer> I think the original request of the bug is correct but the patch is wrong in several places. It's ok to look for .in files in aux dir but we should not build intltool-merge/intltool-merge.out and friends in aux dir. They are built files so they should go in build directory. If it was my module I'd just revert to previous these changes using cvs and commit a correct patch when it's ready. If my analysis of the problem is correct there are more things that needs to be reverted then things that should be kept, so patching over it again we risk to make mistakes. Though this is up to kenneth ;)
I'd agree with Marco: revert the patch, it clearly made things worse. Where the built files go, I don't care, but anything that gets distributed in the resulting "make dist" output should end up in the AUX_DIR, I think.
Marco, you are right. The patch doesnt revert everything. Can you look into this Thomas and then revert everything that was committed then? Kees, I hope you have time to look into creating a correct patch.
I've got something that seems to work for distcheck now. However, I get this at the end: ERROR: files left after distclean: ./po/example.pot ./intltool-extract ./intltool-merge ./intltool-update And I'm not really sure where those should be handled.
Actually... I just ran my example with stock 0.28 intltool, and distcheck fails. I don't think my patch caused this. However, the following patch is "better" than the other one.
Created attachment 22784 [details] [review] Doesn't break distcheck as badly
That sounds good. I don't know where they are best handeled either. Maybe others cc'ed to this bug do know :-) Please attach your patch so people can review it and give it a test run. Kenneth
(Wow! Comments 1 second apart. Nice.) (BTW, that patch is against 0.28)
Yeah, I can revert the complete set of patches, I just did something that allowed me to make distcheck modules. Kees, if your example tarball is what you want to pass make distcheck, then I can cook something up that works for both of us. Just let me know. Tomorrow I'll revert the two patches completely, then look at it.
+ if $cur/$auxdir/$mkinstalldirs $dirname; then I think we cannot assume $auxdir is relative. See http://olympus.het.brown.edu/cgi-bin/info2www?(autoconf)Input Another problem I noticed, that was also in the original code is that $mkinstalldir can be === echo mksinstalldir. In that case $cur/$mkinstalldirs is not going to work. About the distclean error, that's done in some modules with: DISTCLEANFILES = \ intltool-extract \ intltool-merge \ intltool-update Maybe there is a better way though ...
My example was designed to show off the 0.28 bug. With my current patch, it passes my stuff, but seems to slightly blow up in distcheck. I'm not sure how to handle the errors show in my 2003-12-30 18:13 comment. Whatever works! :) I just want intltool to work with AUX_DIR. :) As for the auxdir-is-not-relative problem, I'm not sure how to handle it.
closing this bug for cleanliness as a dup of new bug 130280, where a fix is attached.
*** This bug has been marked as a duplicate of 130280 ***