Re: GOP-PROP 5: build system output (probable decision)

[Graham Percival]

On Thu, Jul 21, 2011 at 07:49:01AM +0100, Trevor Daniels wrote:
> 
> Graham Percival wrote Thursday, July 21, 2011 6:37 AM
> 
> >Not much response from the previous GOP-PROP 5 (update); I'm not
> >certain if "silence is a form of consent" [1] in this context.
> 
> In my case it's because I have difficulty in understanding precisely
> what the effect of this change will be on any work I do.

The effect should be minimal if the build works; if the build
fails, it should make it easier to find out why it failed.  That
goes both for "make" (which isn't very difficult to decypher at
the moment) and "make doc" (which requires about 3 months of doc
work before somebody is competent at figuring out why something
failed).

> But I have one comment.  By far the commonest use of make
> by developers is to compile the most recent change to C++
> source during the development cycle.  To speed this cycle
> up one usually watches the console to follow progress.

I've noticed a speed-up in the build if I minimize the terminal
window.

> If the compile fails you need to immediately see the error
> messages on the console.  It would be a nuisance if you had
> to fish these out from a file somewhere.

That's the reason for the final point -- in the case of a plain
"make", printing the last 10 or 20 lines of the build log should
give you exactly the same info.

In the case of "make doc", you often have to fish the actual error
message from between 500 and 2000 lines after the end of the
console output.  That causes a lot of problems for new doc
contributors, and there's no good reason for it.  Again, the build
system should just print the relevant part of the relevant log
file... but if you want to look at other parts of the build log,
well, they're still on your disk.  In the current "console only"
output, that info is either lost in the limited terminal buffer,
or else in a monstrous 50 MB log file containing absolutely
everything.

> If the compile and link succeed, you usually ctrl-C out of make
> as soon as linking has finished so you can get on with testing.
> So you need to see the relevant messages on the console
> to determine this.

Hmm.  Perhaps we should have a separate "make bin" target, which
only rebuilds the binary?  i.e. no font rebuild, no doc makeinfo
calls?
(or, if such a target already exists -- which I find quite
plausible -- perhaps we should publicize it better in the CG?)

I don't think that anybody should be watching console output,
ever.  Whenever you type "make", people should get coffee or check
email or start writing other code.

> So, my question is, can you still operate like this with a straight
> make command (no options needed), as this, I believe, is the
> commonest requirement.

Under the proposal, a plain "make" would omit any warnings
produced by gcc / mftrace / makeinfo, but would otherwise behave
the same.  Those warnings would be saved in a file.

Cheers,
- Graham