Fixes missing images in big website page

This is an updated patch to put the missing image files back into http://lilypond.org/doc/v2.15/Documentation/web-big-page.html#examples.

It adds an extra element to the path to ly-examples (web/) which fixes up the links in web-big-page.  It does the same with the css address.  These extra elements are then parsed out with postprocess_html.py and website_post.py.  The latter file change is the new feature of this patch - it ensures that the split web pages are valid after make website and also make doc.  I have used this patch and compiled from scratch and see both web-split and web-big have the example images and use the style sheet.

To test this.  Apply the patch.  make website - do you see images and styles in /lilypond-git/build/out-website/website/index.html.  make; make doc.  Do you see images in web-split and web-big?  If these are yes, then the patch is OK.

[PhilEHolmes, 2011-08-25 12:32:54]

Please review.

[Graham Percival (old account), 2011-08-26 20:57:48]

I'm a bit confused about what you're trying to do here (the git-cl confusion
doesn't help).  I am also concerned that you're trying to do complicated build
stuff without being able to test it with the **full** website-only build.

I really, really suggest that you get the full website-only build working before
you continue looking at this.


Instructions for git-cl are in the CG, although it's just possible that the
"rest git-cl issue number" bit was only added after 2.15.8 (and thus isn't
online yet).  Short answer:
  git cl issue 0
to reset, then git cl issue 1234 to set it manually to the issue you want to
upload.

http://codereview.appspot.com/4964041/diff/3001/make/website.make
File make/website.make (right):

http://codereview.appspot.com/4964041/diff/3001/make/website.make#newcode57
make/website.make:57: ### only update this when the language compiles correctly!
why are you ignoring this comment?  unless I missed something, we *don't* want
to automatically build all languages!

http://codereview.appspot.com/4964041/diff/3001/scripts/build/create-weblinks...
File scripts/build/create-weblinks-itexi.py (right):

http://codereview.appspot.com/4964041/diff/3001/scripts/build/create-weblinks...
scripts/build/create-weblinks-itexi.py:12: import langdefs
Are you certain that this works when building only the website?  langdefs is a
lilypond python module; it's not available for python in general.  I do not
think this will work for the website-only build.

[PhilEHolmes, 2011-08-27 09:55:25]

This may be a repeat of what's in my reply, but two places is better than none?

I'm trying to get rid of the hard-coded languages in website build, so that
making changes to the language list involves only a single change in the source
files, rather than multiple ones.  This is issue 1795 (but see a comment I'll be
making there later today, after further checking).  I'll try to get the full
website-build working later today.  FWIW the not-quite-full website build (i.e.
the standard one most people would run) does work fine.

http://codereview.appspot.com/4964041/diff/3001/make/website.make
File make/website.make (right):

http://codereview.appspot.com/4964041/diff/3001/make/website.make#newcode57
make/website.make:57: ### only update this when the language compiles correctly!
I wasn't ignoring the comment.  I read it as saying that we should only add a
language to the list when it compiles clean.  Perhaps this warning should be
added to langdef.py?

http://codereview.appspot.com/4964041/diff/3001/scripts/build/create-weblinks...
File scripts/build/create-weblinks-itexi.py (right):

http://codereview.appspot.com/4964041/diff/3001/scripts/build/create-weblinks...
scripts/build/create-weblinks-itexi.py:12: import langdefs
Yes.  In truth I'm not sure why, but this runs quite happily with make website. 
It will not run if you try to run create-weblinks-itexi.py from the command
line, so there must be paths added during the make.

[Jean-Charles, 2011-08-27 10:35:40]

Le 27/08/2011 11:55, PhilEHolmes@googlemail.com disait :
> This may be a repeat of what's in my reply, but two places is better
> than none?
>
> I'm trying to get rid of the hard-coded languages in website build,
> so that making changes to the language list involves only a single
> change in the source files, rather than multiple ones. This is issue
> 1795 (but see a comment I'll be making there later today, after
> further checking). I'll try to get the full website-build working
> later today. FWIW the not-quite-full website build (i.e. the standard
> one most people would run) does work fine.
>
>

It just comes to my mind that John had build a script for helping
translators to know what has changed and should be reviewed. We then run

make ISOLANG=ll check-translation

Why not get inspiration from this and have (for doc and web) a

make ISOLANG=ll target

function?

And if I want to disable a language when building the docs, I use line
74 of langdefs.py


HTH
Jean-Charles

[email_philholmes.net, 2011-08-27 10:38:57]

----- Original Message ----- 
From: "Jean-Charles Malahieude" <lilyfan@orange.fr>
To: <PhilEHolmes@googlemail.com>; <percival.music.ca@gmail.com>; 
<lilypond-devel@gnu.org>; <reply@codereview.appspotmail.com>
Sent: Saturday, August 27, 2011 11:35 AM
Subject: Re: Fixes missing images in big website page (issue 4964041)


> Le 27/08/2011 11:55, PhilEHolmes@googlemail.com disait :
>> This may be a repeat of what's in my reply, but two places is better
>> than none?
>>
>> I'm trying to get rid of the hard-coded languages in website build,
>> so that making changes to the language list involves only a single
>> change in the source files, rather than multiple ones. This is issue
>> 1795 (but see a comment I'll be making there later today, after
>> further checking). I'll try to get the full website-build working
>> later today. FWIW the not-quite-full website build (i.e. the standard
>> one most people would run) does work fine.
>>
>>
>
> It just comes to my mind that John had build a script for helping
> translators to know what has changed and should be reviewed. We then run
>
> make ISOLANG=ll check-translation
>
> Why not get inspiration from this and have (for doc and web) a
>
> make ISOLANG=ll target
>
> function?
>
> And if I want to disable a language when building the docs, I use line
> 74 of langdefs.py
>
>
> HTH
> Jean-Charles

My proposed patch also uses langdefs.py for the website build.  See also my 
note to Issue 1795 about building a single website/doc version.

--
Phil Holmes

[Graham Percival (old account), 2011-08-27 12:47:26]

http://codereview.appspot.com/4964041/diff/3001/make/website.make
File make/website.make (right):

http://codereview.appspot.com/4964041/diff/3001/make/website.make#newcode57
make/website.make:57: ### only update this when the language compiles correctly!
On 2011/08/27 09:55:25, PhilEHolmes wrote:
> I wasn't ignoring the comment.  I read it as saying that we should only add a
> language to the list when it compiles clean.  Perhaps this warning should be
> added to langdef.py?

I don't mind having broken translations in the main documentation (IIRC every
language is broken in some respect), but I don't want the main public website
having a significantly broken translation.

I'd rather keep this list separate.  I suppose that technically it could still
be put into langdefs.py and define a list of "all translations" and another list
of "website-approved translations", but that would involve a lot more playing
with the build system and I don't think it's worth it.  I guess I'm not opposed
to it in principle, as long as the build still works for all cases.

http://codereview.appspot.com/4964041/diff/3001/scripts/build/create-weblinks...
File scripts/build/create-weblinks-itexi.py (right):

http://codereview.appspot.com/4964041/diff/3001/scripts/build/create-weblinks...
scripts/build/create-weblinks-itexi.py:12: import langdefs
On 2011/08/27 09:55:25, PhilEHolmes wrote:
> Yes.  In truth I'm not sure why, but this runs quite happily with make
website. 
> It will not run if you try to run create-weblinks-itexi.py from the command
> line, so there must be paths added during the make.

Please note that the full website build must work without running ../configure
or make.  I really don't think that you can get away with an import langdefs
here -- at least, not without changing many more parts of website.make.