[systemd-devel] [systemd-commits] Makefile.am
lennart at poettering.net
Fri May 29 06:56:52 PDT 2015
On Fri, 29.05.15 12:26, Daniel Mack (daniel at zonque.org) wrote:
> On 05/29/2015 12:07 PM, Lennart Poettering wrote:
> > On Fri, 29.05.15 03:03, Daniel Mack (zonque at kemper.freedesktop.org) wrote:
> >> Makefile.am | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> New commits:
> >> commit 6096d9ccc3f0b963010a47febce7e44c8632c23b
> >> Author: Daniel Mack <daniel at zonque.org>
> >> 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 Poettering, Red Hat
More information about the systemd-devel