Reduces langdefs.py warnings in doc build

Reduces langdefs.py warnings in doc build

Doesn't quite get rid of them - one to sort.  This has been interesting to fix.  There were 2 issues - building the regtests before building the docs meant that the translations weren't available, and this threw about 20 warnings.  I've swapped their order in the makefile with no apparent other problem.  Building the manuals threw about 10 warnings.  However, it doesn't appear possible to build the translations before the manuals because of a dependency.  To that end, I've added an environment variable to the call to lilypond-book, and suppressed the warning when this variable is set.

[PhilEHolmes, 2012-08-27 13:57:49]

Please review

[John Mandereau, 2012-08-27 14:37:31]

I don't see the point of hiding/getting rid of these warnings, when
1) for now these warnings are harmless outside Documentation/??
2) if you want to get rid of the cause of the warning it should require not more
than adding at the beginning of generic-targets.make:doc-stage-1

make -C $(top-build-dir)/Documentation/po out=www messages

(and possibly "make -C $(top-build-dir)/python out=")

(Similar trick could apply to test/test-baseline/check.)

http://codereview.appspot.com/6487046/diff/1/python/langdefs.py
File python/langdefs.py (right):

http://codereview.appspot.com/6487046/diff/1/python/langdefs.py#newcode101
python/langdefs.py:101: if not os.environ.has_key ('NO_GETTEXT'):
This doesn't make sense to me: if you want to disable the warning below warning
in all cases, which is what the patch seems to do, why not just remove the "if
os.environ.has_key ('LYDOC_LOCALEDIR')" block?

[mail_philholmes.net, 2012-08-27 14:48:26]

----- Original Message ----- 
From: <john.mandereau@gmail.com>
To: <PhilEHolmes@googlemail.com>; <graham@percival-music.ca>; 
<reinhold.kainhofer@gmail.com>
Cc: <reply@codereview-hr.appspotmail.com>; <lilypond-devel@gnu.org>
Sent: Monday, August 27, 2012 3:37 PM
Subject: Re: Reduces langdefs.py warnings in doc build (issue 6487046)


>I don't see the point of hiding/getting rid of these warnings, when
> 1) for now these warnings are harmless outside Documentation/??

http://lilypond.org/~graham/gop/gop_9.html - "By default, no other output 
will be displayed on the console".  These warnings are pointless - they 
always occur and require no fix.  They can confuse new contributors.  So we 
should get rid of them.

> 2) if you want to get rid of the cause of the warning it should require
> not more than adding at the beginning of
> generic-targets.make:doc-stage-1
>
> make -C $(top-build-dir)/Documentation/po out=www messages

I tried building po before Docs but there seemed to be a dependency.  I'll 
have another look.

> (and possibly "make -C $(top-build-dir)/python out=")
>
> (Similar trick could apply to test/test-baseline/check.)
>
>
>
> http://codereview.appspot.com/6487046/diff/1/python/langdefs.py
> File python/langdefs.py (right):
>
> http://codereview.appspot.com/6487046/diff/1/python/langdefs.py#newcode101
> python/langdefs.py:101: if not os.environ.has_key ('NO_GETTEXT'):
> This doesn't make sense to me: if you want to disable the warning below
> warning in all cases, which is what the patch seems to do, why not just
> remove the "if os.environ.has_key ('LYDOC_LOCALEDIR')" block?

It doesn't disable it in all cases.  lilypond-book is called many times in a 
doc build (e.g. for regtests).  This only disables it for the build of the 
manuals.

--
Phil Holmes 

[John Mandereau, 2012-08-27 20:45:14]

http://codereview.appspot.com/6487046/diff/1/GNUmakefile.in
File GNUmakefile.in (right):

http://codereview.appspot.com/6487046/diff/1/GNUmakefile.in#newcode12
GNUmakefile.in:12: input
Switching the build order of subdirectories here should not be relevant for
solving the issue, if you need it this is a signe of a design defect; for
instance the defect (which comes from my introduction of POs for translations in
the first place) is not building LYDOC_LOCALEDIR early enough in the build
process; so switching the build order of these two big trees just for having a
few .mo files built or hiding a warning about them not being built is not a good
motivation IMHO, and might have unwanted effects in the build process (look, it
took us two days of fiddling and testing to fix GUB build for releasing 2.17.0
and end up with small fixes in lilypond:3772b2c7d022122eb9c791bd4a32178e76b97014
and gub:15a6a8dee8f5aa8040baf678f4ed00031c4cf6a9).

[email_philholmes.net, 2012-08-31 15:04:52]

----- Original Message ----- 
From: <john.mandereau@gmail.com>
To: <PhilEHolmes@googlemail.com>; <graham@percival-music.ca>; 
<reinhold.kainhofer@gmail.com>
Cc: <lilypond-devel@gnu.org>; <reply@codereview-hr.appspotmail.com>
Sent: Monday, August 27, 2012 3:37 PM
Subject: Re: Reduces langdefs.py warnings in doc build (issue 6487046)


>I don't see the point of hiding/getting rid of these warnings, when
> 1) for now these warnings are harmless outside Documentation/??
> 2) if you want to get rid of the cause of the warning it should require
> not more than adding at the beginning of
> generic-targets.make:doc-stage-1
>
> make -C $(top-build-dir)/Documentation/po out=www messages
>
> (and possibly "make -C $(top-build-dir)/python out=")
>
> (Similar trick could apply to test/test-baseline/check.)


I've just got back on this, and confirmed that adding

$(MAKE) -C $(top-build-dir)/Documentation/po out=www messages

to the top of the doc-stage-1 recipe gets rid of the warnings, so in fact it 
makes the build work correctly.  I've run a full make/make doc/make test 
with this change and would like to push directly to staging - given that it 
was John's suggestion, he knows what he's talking about, and it works and 
it's a further step in reducing the cruft from make doc.

Any objections?

--
Phil Holmes 

[John Mandereau, 2012-08-31 21:30:18]

Il giorno ven, 31/08/2012 alle 16.04 +0100, Phil Holmes ha scritto:
> I've just got back on this, and confirmed that adding
> 
> $(MAKE) -C $(top-build-dir)/Documentation/po out=www messages
> 
> to the top of the doc-stage-1 recipe gets rid of the warnings, so in fact it 
> makes the build work correctly.  I've run a full make/make doc/make test 
> with this change and would like to push directly to staging - given that it 
> was John's suggestion, he knows what he's talking about, and it works and 
> it's a further step in reducing the cruft from make doc.
> 
> Any objections?

Go ahead.

Thanks,
John