> The idea of diffing 2 builds is truly a cool one - especially when
> they're huge - but I'd rather it was done according to keys or other
> factors e.g. target name.
This sounds like a case for wrapping all rules in a generic output
controller that can be configured (for an incremental build, just
wanting to see whether changes broke anything and get a build on which
to test a fix) to just produce output as normal or (for the build
server's full builds with diff support) emit output (possibly with extra
run-time information) to a file per target: e.g.
ifeq ($(AUTOBUILD),yes)
run = time $1 >$@.log
else
run = @ $1
endif
target: $(PREREQS)
$(call run, $(CMD) $(CMDFLAGS) -o $@ $^)
etc. (This is overly simple; when the commad is a full shell script as
a list separated by semicolons, time is only going to work on the first
sub-command. My intent is only to sketch the approach.)
Then commit all the log files to git and use git show to find out which
of them have changed since the last build. (I trust you can all work
out the equivalent steps for *your* preferred SCM system.) This only
has to happen on the server that builds from clean on a regular basis.
i.e. better done by how you use make than by changing how make works.
(What proportion of proposed "improvements" to make fit that bill ?)
One might be tempted to add a way for make to be told a function in
which to wrap every command-invocation, so that we don't need the
$(call, run ...) round every rule's recipe. Not sure there's a nice way
to do this, though. Also, those who want build diffs probably only
really want them on certain commands, not indiscriminately on all, and
may want to wrap some commands differently than others; e.g. reporting
time use may be relevant in some cases just noise for others.
Another idea on similar lines would be a way to annotate a rule with a
file-name, such that all output of that rule goes to that file (even the
command-line being invoked, if reported); obviously, the "file-name"
would need to support use of $@, $< and perhaps some of their friends.
(This last is why hacking SHELL isn't a promising approach.) But it'd
be necessary to make it easy for a makefile to toggle such annotations
on and off, so that they're only applied when useful..
In particular, note that diffing build logs is only useful for a
build-from-clean such as a build server does; for incremental builds,
deterministic ordering would merely interfere with the immediacy of
seeing my stuipid mistakes so that I can start fixing them while the
rest of the build runs, ready for the next incremental.
> Trying to make a deterministic log would be a tricky way of achieving
> only a small portion of what could be done. It's like putting slick
> [tyres] on a 1920s car - it might help but it's still a long way off
> modern designs.
Indeed ;-)
Eddy.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
