Error making pot file.

[Chris Shoemaker]

On Wed, Jan 04, 2006 at 10:30:30PM +0100, Christian Stimming wrote:
> Okay. Now after testing this I agree that auto-generation of po/POTFILES.in is 
> possible. It is possible because and only because we can rely that "make" in 
> the po/ directory is either run by a "make" in the top-level directory (and 
> SUBDIRS in top-level Makefile.am contains "." first), or if a translator only 
> wants the pot file updated then it will be run by "make pot". I agree that we 
> can provide automatic rules for both cases, so the build won't be broken by 
> this. 
> 
> The build will be broken for the hypothetical case that someone unpacks a 
> tarballs or the autogen.sh'ed SVN, doesn't run make in the top-level 
> directory but instead in the po/ subdirectory. It is okay to break this 
> (seemingly absurd) use of make.

I'll just point out that this (abusive) case is _already_ broken
because of guile-strings.c, so it's fine to leave it broken.

> 
> Therefore I agree that po/POTFILES.in should be removed from SVN altogether.
> 
> HOWEVER, what I still don't see is how your change actually solves the 
> original problem: A file somewhere in the tree was deleted and POTFILES.in 
> wasn't updated. How is your solution going to fix this? Currently I can't see 
> how POTFILES.in will be regenerated for that.

Well, that was the original problem _only_ if we assume that
POTFILES.in has to be in svn.  The _real_ original problem was
regularly breaking the build.  And if the process of making gnucash.po
also involves making POTFILES.in, then there's no problem.

IOW, I'm not worried about the precise sequence:

1) `make pot` or `make all` -> generates po/POTFILES.in
2) you remove a file
3) rerun `make pot` or `make all` -> OOPS, po/POTFILES.in not re-made

There are very few people who might both remove files _and_ use
gnucash.po in the same session.  (1? you?)  And I think they _all_
know how to recognize, avoid and/or work-around this case, with very
little trouble.

For that reason (and because I'm hoping ChangeLog will oneday become
more automated) I'm not in favor of adding a dependency on ChangeLog.
It's not even a certain solution anyway, since it doesn't solve the
case where you want the gnucash.po regenerated _before_ you commmit
the file removal or touch the ChangeLog.

IMO, the leading solution is Derek's spliting the rule in two.  I
think that accomplishes the main objective: someone who does `svn co`
or gets a tarball will never see another broken build from extra
filenames in po/POTFILES.in.

I plan on removing my misguided stub and implementing Derek's solution
today.

-chris