Am Sonntag, den 13.09.2020, 11:59 +0200 schrieb Han-Wen Nienhuys: > On Sat, Sep 12, 2020 at 11:28 AM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > > > > Similarly, if I change a documentation string in an SCM file like > > > > > `define-markup-commands.scm`, the documentation doesn't get > > > > > rebuilt, either. > > > > > > > > I can look at reintroducing the SCM -> texi dependencies. > > > > > > Please do so. Due to the auto-generation process, it is far from > > > trivial to find out which command has to be called. > > > > Actually, I value faster incremental builds that sometimes does less > > over wasting my time always regenerating the internals manual whenever > > I happen to touch an SCM file. Just doing > > $ rm Documentation/out*/en/internals.texi > > will update it, no need to remember any command. > > I see the value of faster builds, but I think being correct is more > important than being fast.
Being fully correct here means generating internals.itexi whenever *something* in the lilypond binary changes - Scheme functions defined in C++ also end up in there. That's basically on touching any file. Ideally, we could make internals.itexi depend on the result of $(top-build-dir)/lily/$(outdir)/lilypond and only generate a temporary copy. If that is the same as before, nothing has to be updated. I've seen this realized with some move-if-changed for other projects, but it looked very hacky back then... > What annoys me is that the default build creates the info docs, which > aren't necessary for developing lilypond. I guess that has to stay because we want distributions building from the tarball to ship the info files to their users... Jonas
signature.asc
Description: This is a digitally signed message part