On Sun, Jun 06, 2010 at 07:29:03AM -0600, Carl Sorensen wrote:
>
> I'm moving all of the detail out of 3.6.3 Post-compilation options into 8
> Regression tests.
Great!
> You can learn more about testing in the
> documentation." (I can't put a link here, because this is part of the
> COMPILING file).
I think you mean INSTALL.txt. We currently *do* have such links,
such as in the very first text paragraph of that file.
I suppose we could discuss if we *should* have those links, or how
they should be formatted, or some-such. However, I veto that
discussion for now. We've spent *far* too much time recently
talking about doing stuff and not actually doing it.
(if somebody desperately cares about this particular item, add it
to the tracker as priority-postponed, with a note that I'm being a
jerk and refusing to discuss/decide anything until later)
With that in mind, please add a link. Since it's in
Documentation/included/compile.itexi, you need to use @rcontrib{}
even though you're linking within the CG.
> I've reordered CG 8. Tentative organization is:
>
> Introduction to regression tests
> Precompiled regression tests
> Regression test output
> Regression test comparison
> Compiling regression tests
> Identifying code regressions
> Other tests
> Checking memory usage
> Checking code coverage
> MusicXML tests
I don't like "other"... what about "Performance tests"? no wait,
that doesn't work for code coverage. Hmm.
Separate topic: is the distance-output script going to be
discussed in Compiling regression tests? In my mind, there's a
difference between compiling the regtests (i.e. "do any errors
break compilation?") and examining the before+after changes for a
patch.
> I haven't yet figured out where the information on what you need to do after
> modifying fonts should go. My recent experience has shown me that you don't
> need to do a make clean after modifying fonts. It's sufficient to do rm
> mf/out/*; that triggers a font rebuild.
*shrug*
I wouldn't expect that to make a huge difference in time, although
of course if you're doing heavy font work, I guess that saving 3-4
minutes for each compile *would* help a lot.
For now, I'd dump it somewhere in the Programming chapter;
eventually we might split off a Font chapter from that. But I'd
really caution against trying to juggle too many balls at once --
dump it somewhere and then focus on the Regressions chapter.
> I also haven't yet decided where to put the whole "Typical developer's
> edit/compile/test cycle" node. I'm currently thinking that there should be
> a section in the CG on "The LilyPond build system", but I haven't worked
> that out fully yet.
There's already one in CG 3. It doesn't particularly belong
there, but I was dumping it somewhere to avoid too much juggling.
> But since you got me started, here's my initial draft:
>
> The LilyPond build system
> Intro to build system
> Make
> Auxiliary scripts
> GUB
GUB is discussed in Releases. I don't think that needs to change.
> 3.10 would go away under this organization.
oh, oops, you already knew about it.
> Of course, as this is a major reorganization of the docs, I'll post a patch
> on Rietveld before committing.
I'm seeing too much juggling. Focus on the Regressions -- dump
all other info into the CG (anywhere that makes remote sense,
other than CG 1, 2, and 7). Don't bother with a patch-review for
that info-dump. Then work carefully on Regressions, post a patch,
etc.
We'll come back to those other sections later.
Cheers,
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
