On Fri, 29.05.15 12:26, Daniel Mack ([email protected]) wrote: > On 05/29/2015 12:07 PM, Lennart Poettering wrote: > > On Fri, 29.05.15 03:03, Daniel Mack ([email protected]) wrote: > > > >> Makefile.am | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> New commits: > >> commit 6096d9ccc3f0b963010a47febce7e44c8632c23b > >> Author: Daniel Mack <[email protected]> > >> Date: Fri May 29 12:00:58 2015 +0200 > >> > >> Makefile: make custom-entities.ent depend on Makefile.am > >> > >> When Makefile.am is modified, make sure custom-entities.ent is rebuilt. > >> After all, $(substitutions) is defined there, so changes of that > >> variable > >> must be reflected in the resulting file. > > > > Hmm, so we used have a lot of rules like this that mathematically > > correctly rebuilt really everything touched by a change. However, this > > resulted in soo much wasted build time, that we removed parts of it > > again, even if this means that some man pages might be slightly out of > > date if the Makefile.am changes. > > > > hence: what is the impact of this change precisely? does this mean a > > slight change of the makefile will always result in all man pages to > > be rebuilt? we don#t do that for the C compilation logic when a > > Makefile.am changes, so should we do this in this case? > > This came up during the hackery around the custom entity logic. With > changes to what $substitutions in Makefile.am contains, the resulting > file man/custom-entities.ent was never rebuilt, and hence went out of > date and had to be deleted manually. > > But yes, that means the man pages will now be rebuilt every time > Makefile.am is touched of course.
I'd prefer if we would avoid that. The xsltproc stuff already is the slowest part of the build, and I wish touching the makefile would not cause a full rebuild of that. I think it's ok to expect people to run "make clean" after touching the makefile to get the man pages fixed. Hope that makes sense, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
