On Sun 2019-04-21 16:29:02 -0300, David Bremner wrote:
> the html rebuild is much faster than the texinfo + info rebuilds.

agreed, in the runs that i've been doing as well.  I was concerned that
the html rebuild itself may have been *triggering* the rebuild of the
texinfo stuff, though.  Sounds like you don't think that's the case.

> I've posted some patches for the sphinx-doc issues a couple of hours ago
> (id:20190421171245.19729-1-david@tethera.net). 

thanks!  your own commentary on that series seems to acknowledge that
there are problems with it (though i don't understand the tradeoffs
well).  i'm not super comfortable with make-style "stamping": my
experience with it is that it creates a synchronization problem, and
it's easy for the "sync" between the stamp and the generated artifacts
to break, at which point the safest thing is to "make clean" and start
fully over.

Is there no way to give make itself full visibility into the specific
generated files so it can do its comparisons directly?  I'm obviously
not asking you to rewrite the entire native sphinx build system, i'm
just observing that at present it seems suboptimal, though i don't know
how to fix it either :/

> Currently the ruby rebuild doesn't seem to be slowing things down much
> for me.
>
> ╭─ convex:~/software/upstream/notmuch 
> ╰─ (git)-[wip/make-docs]-% /usr/bin/time make ruby-bindings 1>/dev/null
> 0.13user 0.02system 0:00.15elapsed 101%CPU (0avgtext+0avgdata 11504maxresident)k
> 0inputs+208outputs (0major+6523minor)pagefaults 0swaps
>
> That's with an SSD, so maybe there's more of hit for other environments.

I agree, this one isn't particularly slow, and it appears to be a leaf
dependency (for now), so it's not the worst thing.  But it's still
pretty clearly a bug that this thing loops.

       --dkg