GNOME Bugzilla – Bug 69947
intltool makes update-po during "make dist" fail harmlessly when srcdir != builddir
Last modified: 2009-08-15 18:40:50 UTC
The rules substituted by intltool's macros seem to fail for srcdir != builddir builds in some cases (such as those done by "make distcheck"). It looks like the rules are searching for the .in files in the build dir rather than $(srcdir)/.
It's strange. Gman was reporting the same problem, but I know that I build nautilus with "make distcheck" before every release, and it's working. Are you specifically talking about gnome-core? Because that's the same library Gman was struggling with.
I ran into the problem when trying to distcheck dia. I don't know what the exact reasons it works for some and not others. If it makes any difference, I was using automake 1.5 (which makes the srcdir readonly during distcheck). The fix might be as simple as changing $< to $(srcdir)/$< in the rule. The rule for generating .o files from .c files is a little more complex and uses the following: `test -f $< || echo '$(srcdir)/'`$< That extra test might just be to handle generated .c files though (which would be in the builddir).
Created attachment 6551 [details] [review] intltool.m4 patch
This is the attachment that James suggested. I haven't managed to test it yet though.
I'm not sure I understand why it's a good idea to change $< to $(srcdir)/$<. First, as I understand it, the problem was finding the intltool-merge script, not the source file. Second, I believe that make is responsible for setting $< to the path of the prerequisite file, and if it's not in the current directory, it will be either an absolute or relative path to the file.
Sorry, stupid wrapping bug in bugzilla: I'm not sure I understand why it's a good idea to change $< to $(srcdir)/$<. First, as I understand it, the problem was finding the intltool-merge script, not the source file. Second, I believe that make is responsible for setting $< to the path of the prerequisite file, and if it's not in the current directory, it will be either an absolute or relative path to the file.
This problem is minor, because none of the real functions fail. The only thing that fails is the update of .po files that's done as part of the "make dist" process. This happens because the update-po rules does a cd $(srcdir). Once it does that, the path to find intltool-update in $(topbuilddir), which is a relative path, doesn't work any more. It would be nice to fix this, but it's low priority. The scripts have been broken in this way since xml-i18n-tools was invented. I'm glad we at least noticed now. I think James's patch fixes another problem, which may not exist. The normal rules handle srcdir != builddir just fine. But perhaps James was reporting a separate problem from the one Glynn and I debugged.
Darin, this bug also happened when srcdir == builddir.
That's not true. When srcdir == builddir you saw this happening in the check part of "make distcheck". But that uses srcdir != builddir always.
Upping priority (since it affects builds) and marking triaged; just ignore lil 'ol me.
I think your idea that this "affects builds" is wrong. All this does is prevent the extra update of po files when doing a "make dist" from happening. That doesn't cause any real problems. If you know of any real problem this causes, feel free to mention it here and up the priority and severity.
Created attachment 6874 [details] [review] may address some problems, cause others
The patch I just attached is one I sent to Darin that fixed the $(GENPOT) rule for me. Most of it is untested and no doubt causes problems, but hopefully it's a step in the right direction.
Darin: happy to accept things if I'm wrong. :) Thanks for correcting me.
I see make distcheck failing in The GIMP too. It doesn't fail in po directories but in data/misc where we have the following rule: gimp.desktop: gimp.desktop.in $(wildcard $(top_srcdir)/po/*.po) sed -e 's|.[{]prefix[}]|${prefix}|' $< > desktop-foo \ && $(INTLTOOL_MERGE) $(top_srcdir)/po desktop-foo $(@) -d -u -c $(top_builddir)/po/.intltool-merge-cachemake \ && rm -r desktop-foo $(INTLTOOL_MERGE) expands to $(top_builddir)/intltool-merge which is not the location of the script. The correct location would be $(top_srcdir)/intltool-merge. This breaks if srcdir != builddir. IMHO the correct fix is to change $(top_builddir) to $(top_srcdir) in intltool.m4: -INTLTOOL_EXTRACT='$(top_builddir)/intltool-extract' -INTLTOOL_MERGE='$(top_builddir)/intltool-merge' -INTLTOOL_UPDATE='$(top_builddir)/intltool-update' +INTLTOOL_EXTRACT='$(top_srcdir)/intltool-extract' +INTLTOOL_MERGE='$(top_srcdir)/intltool-merge' +INTLTOOL_UPDATE='$(top_srcdir)/intltool-update' This is a rather serious problem since I really want to be able to create tarballs using make distcheck. Please consider assigning it a higher priority.
This doesn't prevent you from creating tarballs using make distcheck. Specifically what's wrong with the resulting tarballs? Is changing intltool.m4 to look in $(top_srcdir) correct? These intltool-* files are created from the intltool-*.in files as part of the configure process. I didn't realize that configure was allowed to put files in srcdir. I'm pretty sure it's not that simple.
Well, make distcheck does create tarballs for me but those tarballs don't compile for builddir != srcdir which is essentially what make distcheck tests. We have often received complaints about srcdir != builddir brokeness so it seems that people actually do this. I have now rerun make distcheck with intltool.m4 changed as suggested and it didn't help. Looks as if you are right. The change I suggested is most probably wrong and it does definitely not solve my problem. The problem seems to be somehow GIMP-specific since what actually goes wrong is: neo@bender:~/gnomecvs/gimp-dist/gimp-1.3.4/=build$ ./config.status creating po-plug-ins/Makefile.in creating po-script-fu/Makefile.in creating config.h config.h is unchanged ./config.status: ../../po-script-fu/intltool-extract.in: No such file or directory I have no clue what is going wrong but I'll investigate further...
OK. Sounds like you are talking about another problem, not this bug. So please open a separate bug report if you find it's something else wrong with intltool.
I compile all my gnome 2 stuff with $srcdir != $builddir and all my intltool scripts are found in $top_builddir. Though I guess maybe if the generated intltool-foo scripts are put in the tarball, Sven's problem will occur? I don't know if this is the case but it could cause the problem, I think.
Looking at the intltool patch above I don't see how it fixes the problem since it doesn't change the 'cd $(srcdir)' that is causing the problem. What we've done in similar cases is frequently something like: intltool=`pwd`/../intltool-update && cd $(srcdir) && $$intltool .... Though adapting that would take a bit of work. (I agree that Sven's problem is something different ... looks like distributing the wrong files to me.)
Here is a patch against my Makefile.in.in that fixes the problem that update-po writes to $(srcdir) and therefore breaks distcheck. The fundamental problem is that the intltool family tools expects $(GETTEXT_PACKAGE).pot to be in the dir they are runned without explicity stating it in the commandline. If it was explicitly stated then make would have found them in VPATH. The workaround is to copy $(GETTEXT_PACKAGE).pot to $(builddir) and then remove it in distclean. The patch is against Makefile.in.in from glib-gettextize in glib2-devel-2.0.6-2 that is patched by intltoolize from intltool-0.22-3 (all stock redhat 8 versions) How to apply it to intltool/glib is a question I leave to it's respective maintainers :)
Created attachment 11522 [details] [review] fixes update-po to work when $builddir != $srcdir
Can anyone test this patch for me? I never compile with $builddir != $srcdir
Is this still an issue? If so can someone PLEASE test that patch for me. Kenneth
This still happened to me yesterday when I did the gimp-2.0pre1 release. However I had to downgrade intltool to version 0.27.2 because 0.28 as well as current CVS created broken XML files. But that's another issue and I will open a bug report for it when I find the time.
Sven, could you test the patch? btw, when creating the other XML bugs please cc: brian.cameron@sun.com who did the new XML code.
Running make dist in the gimp tree takes a good while. But if you can fix my intltool problems so that I can use the newest version, I will happily test the patch when doing the next release (which should happen in about two weeks).
Adding the PATCH keyword.
Comment on attachment 6874 [details] [review] may address some problems, cause others Owen said this patch did not do the right thing, so marking needs-work. There are still other patches on this bug- someone with clue should take a look and mark appropriately.
I have no idea on how to fix this - so I hope someone will step up.
I'm having other problems doing "make distcheck" in CVS HEAD of gimp from today, but "make dist" completes after building gimp in the CVS tree, so that it can link gimp-console properly. Now it's failing to find gimpressionist.c. However, all the intltool-related things seem to work. I'm tempted to close this as FIXED for real now. Sven?
Well, 'make dist' has always worked. I will try to run 'make distcheck' using intltool from CVS and will get back to you.
Any news on this Sven?
OK. So. I've fixed quite a few builddir != srcdir issues in intltool. We can't have update-po run automatically any more, because of this, since it's utterly useless to run update-po and have it write new po files to builddir instead of srcdir, since po files are kept in CVS, and need to be in the tarball and whatnot. As a result of this, I have disabled the "update-po" rule from being run automatically at dist time now. All of the issues for this bug should be fixed. If they are not, please open a new bug against intltool 0.33 describing new problems. Thanks. I'm just going to go ahead and close this, since there's been no response in a while, and it hasn't been reopened.
Rodney, have you discussed this change with the translators? Not running update-po from the 'dist' target is a pretty severe change in behaviour. I hope you discussed this with the relevant people beforehand.
Sven, most translators not versed in CVS (and most aren't) actually hate to have to resolve conflicts resulting from changed PO files in CVS (and the extent of the changes is such that it's unusable to try to fix conflicts following markers CVS inserts in files). Most don't even know about dot-files which contain previous versions, so they end up retranslating. From their POV, it's very good not to have update-po run with every tarball (this was discussed on gnome-i18n before), but I still think it should be run occasionaly, so we don't end up with completely obsolete translations in tarballs (so, perhaps before first stable release?).
I don't see why one would have to resolve conflicts. That's what msgmerge is for. Anyway, I don't have a strong opinion on this. I just wanted to make sure that this change has been discussed with the relevant people.