GNOME Bugzilla – Bug 531893
.po/.pot files are generated in builddir instead of srcdir
Last modified: 2008-05-11 17:34:02 UTC
Please describe the problem: .po and .pot files are generated in the $builddir and hence do not update the .po files in the $srcdir. I work with several builddir (native/ and cross/), and it's inconvenient to run ./configure in the srcdir, because then the builddir cannot work (error 'configure: error: source directory already configured; run "make distclean" there first'). So I'd like it to work when ran from a builddir. Additionally the source paths in the resulting .po files are not usable because they look like #: ../../po/../src/BZip.cpp:97 A manual 'msgmerge' from srcdir (msgmerge ../native/po/fr.po fr.po > fr.po.new) can post-fix this latter issue. Steps to reproduce: 1. mkdir native && cd native && ../configure 2. cd po && make update-po Actual results: Files are created in $builddir/po/ .po paths are relative to $builddir Expected results: Files created in $srcdir/po/ .po paths are relative to $srcdir Does this happen every time? Yep. Other information:
Yes. Files generated at build time go in builddir, not srcdir, which is for SOURCE. Your "error" has nothing to do with intltool. You will always get that message when doing what you are doing, so long as you use autotools. It has nothing to do with intltool specifically. You can run intltool-update instead of "make update-po" in the srcdir/po directory if you want to update the po files there, to avoid configuring the srcdir, if you wish.
Hi, > You will always get that message when doing > what you are doing, so long as you use autotools. Well, I used gettext (with autotools) and its Makefile.in.in does that job without error. > You can run intltool-update instead of > "make update-po" in the srcdir/po directory This means "update-po" has a behavior that differs from gettext, and that produces confusing results (generates separate .po files in builddir). As in #531892 I think this boils down to non-support for pregenerating .gmo files in releases. Is this intentional? I mark the bug as reopen in case this is a documentation bug (I see intltool as an 'upgrade' from gettext's build system, and such changes needs to be specified in README / README.from-gettext / something like that). After some more research I see this is also reported at: http://bugzilla.gnome.org/show_bug.cgi?id=166724 but there's no explanation there about _why_ :/
(In reply to comment #2) > Hi, > > > You will always get that message when doing > > what you are doing, so long as you use autotools. > > Well, I used gettext (with autotools) and its Makefile.in.in does that job > without error. You ran ../configure inside a build subdir, after running ./configure in srcdir, and it worked? I doubt it. > > You can run intltool-update instead of > > "make update-po" in the srcdir/po directory > > This means "update-po" has a behavior that differs from gettext, and that > produces confusing results (generates separate .po files in builddir). The results are not confusing. They are proper and gettext is not. Files generated when running ./configure or make belong in builddir, not srcdir. Writing files to srcdir at build time is doomed to be problematic. What happens when srcdir is not writable? The build fails. > As in #531892 I think this boils down to non-support for pregenerating .gmo > files in releases. Is this intentional? This is answered in the report you linked below. > I mark the bug as reopen in case this is a documentation bug (I see intltool as > an 'upgrade' from gettext's build system, and such changes needs to be > specified in README / README.from-gettext / something like that). Please do not re-open bugs to convert them to requests in other parts of intltool. If you want to file a documentation request, file it separately. > After some more research I see this is also reported at: > http://bugzilla.gnome.org/show_bug.cgi?id=166724 > but there's no explanation there about _why_ :/ There is a rather obvious explanation that you are simply overlooking because gettext has the same inherent problem. It breaks builddir != srcdir. It is the summary of that bug report, in fact.
Hello, > You ran ../configure inside a build subdir, after running > ./configure in srcdir, and it worked? I doubt it. Ah, in your first answer, I had misunderstood what you error you refered to. > The results are not confusing. They are proper and gettext is not. Hmm, when used for the first time, intltool replaces an existing gettext build system and behaves differently, which is a confusing situation. A paragraph about it in the README would help IMHO. I say this after spending hours trying to understand what went wrong after 'intltoolize'. > Please do not re-open bugs to convert them to requests in other parts of > intltool. If you want to file a documentation request, file it separately. You'll understand that the current tone of the discussion does not entice me to do so. Cheers.
(In reply to comment #4) > > The results are not confusing. They are proper and gettext is not. > > Hmm, when used for the first time, intltool replaces an existing gettext build > system and behaves differently, which is a confusing situation. A paragraph > about it in the README would help IMHO. I say this after spending hours trying > to understand what went wrong after 'intltoolize'. You ran "intltoolize" and expected the same results as "gettextize". I wouldn't call that a confusion on intltool's part. It is like going to McDonald's and expecting to get a Whopper from Burger King. They are not the same thing.