After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 330509 - po/Makefile POTFILES substitution failure
po/Makefile POTFILES substitution failure
Status: RESOLVED NOTGNOME
Product: intltool
Classification: Deprecated
Component: general
0.34.x
Other All
: Normal normal
: ---
Assigned To: Rodney Dawes
intltool maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-09 10:35 UTC by Jules Colding
Modified: 2012-03-16 12:39 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Jules Colding 2006-02-09 10:35:38 UTC
Please describe the problem:
Running autogen.sh makes it create "po/stamp-it" before "make" is executed. This
prevents the creation of my "*.gmo" files. Manually deleting "po/stamp-it" after
autogen.sh makes the problem go away. This manual step is a annoying as it
requires changes to the ".spec" file if I want my translations to be included in
the rpm.

The following change to my spec makes the translations get included:

%build
%configure
rm -f po/stamp-it <== Added manual deltion of stamp-it
make



Steps to reproduce:
1. ./autogen.sh
2. Observe that po/stamp-it exists
3. Execute make
4. Observe that the *.gmo are not created


Actual results:
As described above..

Expected results:
Step 3 should result in the creation of *.gmo files

Does this happen every time?
Yes

Other information:
This does not happen in 0.34.1. 

I am not entirely sure that this is a bug in intltool but the stamp-it file
seems to be created by intltool so...
Comment 1 Jules Colding 2006-02-10 07:56:55 UTC
RPMs to demonstrate the problem here: http://www.omesc.com/content/downloads/dist/
Comment 2 Rodney Dawes 2006-02-12 23:55:22 UTC
I am unable to reproduce this problem with CVS intltool. The gmo files are being created just fine. Are you saying they aren't included in the tarball, and aren't getting created when building from that?
Comment 3 Jules Colding 2006-02-13 08:37:29 UTC
Please download this tarball:

http://www.omesc.com/content/downloads/dist/SOURCES/evolution-brutus-0.9.4.tar.gz

Edit evolution-brutus.spec.in to not delete the "po/stamp-it" file. Then do "./autogen.sh ; make dist-rpm" to see the problem. 

I should add that the dist-rpm target assumes that you have a fedora rpm environment with $(HOME)/rpmbuild as _topdir.
Comment 4 Rodney Dawes 2006-02-14 02:49:26 UTC
The problem is totally unrelated to stamp-it. Your po/Makefile is being created incorrectly somehow. which is quite odd. So, just doing "touch po/Makefile.in.in" and then running make, will also work. It looks like the CATALOGS variable is not being defined in Makefile, in the initial creation of the file. This is of course very odd, as the variable is properly substituted in the Makefile.in.

It looks like there's a race between the standard intltool ac config commands, and the ones for $subdir/stamp-it.
Comment 5 Rodney Dawes 2006-02-14 03:06:03 UTC
OK. It's not actually a race. It looks like there's a bug in the regex to substitute the POTFILES variable in po/Makefile, with the contents of the POTFILES file. A workaround is to remove the secondary newline in POTFILES.in at the end of the file. Your POTFILES.in has 2 newlines, and is causing this issue.
Comment 6 Jules Colding 2006-02-14 08:28:45 UTC
That did indeed work. Not an entirely obvious fix I must add ;-)
Comment 7 Rodney Dawes 2006-02-15 04:55:27 UTC
OK. I've just committed a workaround for this in intltool. I've added a throw-away comment in Makefile.in.in that ends up getting stripped out, rather than the CATALOGS = definition. This at least makes intltool work, albeit a crappy solution.  I'm leaving this open though, until we have a proper solution.
Comment 8 Rodney Dawes 2006-12-20 17:02:35 UTC
OK. I've replaced the useless comment with $(NULL). This makes the Makefile properly valid, and resolves this issue.
Comment 9 Rodney Dawes 2006-12-20 19:37:47 UTC
OK. That doesn't fully work, so I'm reopening this.
Comment 10 André Klapper 2012-03-16 12:39:41 UTC
intltool has switched from the GNOME to the launchpad.net infrastructure nearly three years ago: https://mail.gnome.org/archives/gnome-i18n/2009-April/msg00275.html
The intltool product in bugzilla.gnome.org has been deprecated and closed for new bug entry since April 2009.

I am now closing all remaining open reports about intltool as NOTGNOME as part of GNOME Bugzilla Housekeeping.

Reporter: If the problem that you reported here is still valid in a recent version of intltool we kindly ask you to report it again to https://bugs.launchpad.net/intltool/ so the intltool developers get notified about it.