.gmo files built twice

[Jon Lapham]

Derek Atkins wrote:
> Hi,
> 
> Jon Lapham <lapham at extracta.com.br> writes:
> 
> 
>>1) The gnucash.pot file should depend on the files listed in
>>POTFILES.in.  If one of those files is updated, we should rebuild
>>gnucash.pot
> 
> 
> I'm not convinced this is right, because then you would be rebuilding
> all the files every time a developer rebuilds the system.  So, no, you
> shouldn't need to rebuild the .pot every time, or even when source
> files change.  The only caveat I would present is that if you can make
> the generation of the file based on:
>         a) any of the POTFILES changing, and
>         b) only touch gnucash.pot IFF there are new/removed strings
> 
> In other words, just because a file was touched does not imply that
> you should touch gnucash.pot.  If there are no new/changed/removed
> strings then gnucash.pot should not be changed.  This implies building
> a temporary gnucash.pot, comparing it to the original (ignoring the
> 'build date'), and moving it into place if they differ..

Well, it only takes a few seconds to build the .pot file... which isn't 
too bad if it is only done once in a build (currently it is done "the 
number of .po files" times).  But, I see your point.

>>2) The .po files depend on the gnucash.pot file.
>>
>>3) The .gmo files depend on the .po file.
>>
>>What we currently have is only parts 2 & 3 above, with the extra
>>"gotcha" that every time we make a .gmo file, the .pot file is
>>regenerated.  There is no dependency checking on the POTFILES.in file
>>list!
> 
> 
> Well, POTFILES.in generates POTFILES, but even so I'm not sure how you
> can create a make dependency on the _contents_ of the file.  You can
> certainly make a dependency on the _timestamp_ of the file -- so if
> the POTFILES changes it all gets rebuilt.  But the POTFILES rarely
> change.

The dependency for the contents of the file comes from the definition of 
$(POTFILES) in the Makefile itself.  It is defined as a huge list of all 
the files found in the POTFILES.in file.

>>So, after making a .gmo file, the gnucash.pot, .po and .gmo files are
>>all regenerated.
> 
> 
> This is definitely a bug.  You should not regenerate the .pot just because
> you generated a gmo.
> 
> 
>>After some investigation, I've found the following solution.  First,
>>we need to add the following dependency to po/Makefile (via
>>Makefile.in.in I guess):
>>
>>569c569
>>< $(srcdir)/$(DOMAIN).pot:
>>---
>> > $(srcdir)/$(DOMAIN).pot: $(POTFILES) $(srcdir)/POTFILES.in
>>
>>This will do the dependency checking on the POTFILES.in (if you change
>>a .c file, you need to rebuild the gnucash.pot file).
> 
> 
> Well, no, this is not what this dependency says.  This dependency says
> that if you change the contents of POTFILES or POTFILES.in then you
> will rebuild the .pot.  This says nothing about the contents of the .c
> files in the source tree.
> 

$(POTFILES) *is* a list of the .c files as defined earlier in the 
Makefile.  If one of these .c file gets updated, the .pot file is 
rebuilt.  If they are already uptodate, the .pot file is not rebuilt.

>>Secondly, we need to remark out this line of intltool-update:
>>
>>177c177
>><     &generate_po_template;
>>---
>> >     # &generate_po_template;
>>
>>We should never call "generate_po_template" from within
>>intltool-update, because that is already being handled by the Makefile
>>within po/.
> 
> 
> Hmm..
> 
> 
>>After this, I believe we achieve the desired dependency behavior.  On
>>my system here, a "second" compiling of the source code is MUCH MUCH
>>faster now, and the po/ files *are* rebuilt upon a change to any of
>>the POTFILES.in
>>
>>Comments?
> 
> 
> Well, considering that none of the intltool code is in CVS, changing
> it might be challenging.
> 

Yeah, I agree.  It would be nice if there was a command line argument to 
send to intltool-update to *not* do the .pot file update.

-- 
-**-*-*---*-*---*-*---*-----*-*-----*---*-*---*-----*-----*-*-----*---
  Jon Lapham  <lapham at extracta.com.br>          Rio de Janeiro, Brasil
  Work: Extracta Moléculas Naturais SA     http://www.extracta.com.br/
  Web: http://www.jandr.org/
***-*--*----*-------*------------*--------------------*---------------