Re: Patchy switches for forcing make doc don't seem to work

[James]

John,

On 20 August 2012 14:28, John Mandereau <address@hidden> wrote:
> Il giorno lun, 20/08/2012 alle 13.53 +0100, James ha scritto:
>> On 20 August 2012 13:09, John Mandereau <address@hidden> wrote:
>> > If you mean the BUILD_ALL_DOCS switch in the core code of the builder
>> > (patches/compile_lilypond_test/__init__.py),
>>
>> Yes I was.
>
> The ability to run "make doc" for testing patches that you mention may
> have been lost in some refactoring of the code, but I have no specific
> clue.  Whatever.  Let's make an option for it (not for
> lilypond-patchy-staging though!) and we'll be fine.
>
>
>> A make
>> test test-baseline takes about half that and because I assume ( I have
>> never looked in the code) that if I have multiple patches being tested
>> at once that we keep the same make test-baseline and don't redo it.
>
> Your assumption is correct.  When patchy/test-* is merged with master,
> test-baseline output can even be kept across several Patchy runs,
> provided that master revision doesn't change and the build tree is not
> cleaned up to deleting it, thanks to a checksum of all contents of
> test-baseline directories.
>
>
>> The point is that some patches (like Mike's Skyline or some of Phil's
>> recent contributions) would possibly affect documentation, even some
>> of the more trivial doc-specific patches could break make doc. As make
>> doc is very heavy for most devs, having a way for me to say 'meh...I
>> don't care if rebuild doc on every patch, it's just an extra bit of
>> time', when testing their patches at least gives those devs the
>> confidence that it is being tested and so they don't need to (if you
>> see what I mean). It is one thing as you say for devs to do reg tests
>> or basic make tests but another for make doc.
>>
>> That's where I come in.
>
> Sure.  Even with all the bells and whistles for increasing build speed,
> security and reliability I try to add for running Patchy on Grenouille
> likely won't allow making doc on it for testing each and every patch; it
> has a Pentium 4 and "make doc" needs more than 2h40min, and we have
> 64bit Core2-like or faster.
>
> As for new Patchy code, I'm still fixing errors and keep rewriting
> history of patchy/test* branches, this code needs a few days of
> stabilization before it can be pushed on master (I hope before leaving
> for Waltrop on Thursday evening) and I propose you to test it.

What might be more convenient - depending on the approach - is to be
able to arbitrarily run ./test-patchy.py at a tracker issue regardless
of patch status and build the doc based on it.

That means that I can run ./test-patchy.py normally and then once the
basic tests are done I can run it again and *just* make doc.

At the moment I  use the patch command from a downloaded rietveld diff
file; which works but means I have to manually make sure (and remember
to check) that git is cleared out of any files that get created either
with the new patch or during compilation as they will not be part of
git's history. I don't know how else to get a git formatted patch from
a tracker/rietveld issue and apply it to my own tree to test without
asking for it from the dev.

Just a thought

James