[m-rev.] for review: tighten up checks for invlaid grade in mgnuc script etc

[Zoltan Somogyi]

On Fri, 24 Apr 2015 09:46:01 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > I would object to that. I still use mmake. It is still more controllable
> > for diagnosing problems than mmc --make.
> 
> Fair enough.  Are you also objecting to Peter's proposal?

No. I am fine with both parts: moving documentation for mmake out of the user
guide, and putting the helper scripts in a less-visible directory.

> Out of curiosity: are there features missing from mmc --make that would
> make it as controllable for diagnosing problems as mmake?

It is just that mmake allows you more control over all steps of the build process,
including its interruptions.

When working on bugs, I sometimes want to tell the build system "don't build this .c file
from the corresponding .m file; instead, copy it from this previously-built .c file". That
other .c file could have been built not just with different options, but also with a different
compiler, or simply by editing it by hand; the latter capability comes in especially handy
when you want to insert logging or debugging printfs. Mmc --make can decide
to overwrite my carefully constructed .c file by recompiling the .m file for more
reasons than mmake, so if I don't want that to happen, I have more work to do
defeating every one of those reasons. If I have to, I can preserve the makefile
generated by mmake, modify it, and give the result to make. The modification
may be as simple as "delete all the rules that make a .c file depend on the .int,
.int2 and .int3 files of the modules imported by its .m file", or it may be more
complex than that. You can't do such things with mmc --make, and I don't think
you would even WANT to add that capability to mmc --make.

Zoltan.