Neil Williams schrieb:
A translator _still_ has to either `make pot' or `make' at toplevel
and in either case, POTFILES.in will already exist. Right?
That is the flip side of the OSX problem.
I think all of this can be solved once suitable Makefile rules will be
used (it's unclear to me which part of that was OSX-specific). I agree
that Makefile writing takes quite some time to get used to, but usually
it turns out that all desired dependencies can actually be expressed in
Makefile syntax.
make-potfiles: make-potfiles.in Makefile
rm -f [EMAIL PROTECTED]
sed < $< > [EMAIL PROTECTED] \
-e 's:@-PERL-@:${PERL}:g'
chmod +x [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
Yes.
all-local: Makefile
rm -f ./po/POTFILES.in
./make-potfiles > ./po/POTFILES.in
No, I wouldn't write the commands in the extra "all-local" rule for
that. Instead, I suggest to add an explicit rule for "po/POTFILES.in"
which will contain precisely this: The commands for generating
po/POTFILES.in. (Did you say that OSX wouldn't accept that? In the
aqbanking package we've been using such a subdirectory-file-rule for
years and no-one complained about it.)
AFAICT, the only way to catch all file deletions is to write a new
po/POTFILES.in each time make is run from the top level directory using
all-local because that is what ensures that po/POTFILES.in exists.
Another suggestion: Make po/POTFILES.in dependent on ChangeLog. This
won't trigger its generation upon each "make", but upon each make when
the ChangeLog has been edited. Since by convention the ChangeLog will be
edited after file removals, we are on the safe side. So I propose those
rules instead:
po/POTFILES.in: Makefile make-potfiles ChangeLog
./make-potfiles > ./po/POTFILES.in
pot: Makefile make-potfiles po/POTFILES.in
# add intl-scm for gnucash here
rm -f po/$(PACKAGE).pot
make -C po $(PACKAGE).pot
... and it's up to the reader to decide whether you add a dependency of
"po/POTFILES.in" to the optional "all-local" rule:
all-local: po/POTFILES.in
but IMHO that's not even necessary.
Christian
PS: Yesterday you've written approx. 10 different email answers in this
thread. This makes this discussion thread really difficult to read (as
mentioned by Tor Harald). I'd prefer if you could compress your
answers/discussion into one single thread, which implies answering
several concerns in one single email answer instead of spreading them
out into multiple emails. Maybe matter of taste, but also a matter of
easier legibility in the whole developer group.
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
