[m-rev.] for post-commit review: fix mantis bug 361

[Zoltan Somogyi]

On Thu, 18 Sep 2014 01:50:52 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> Ok.  Here are the grade components that I think should be visible to users
> and publicly documented:
> 
> Base grades: none, reg, asm_fast, hlc, java, csharp, erlang
> 
> Rationale: most of the other base grades exist only to test various compilation
> model options that were never intended to be visible to users.  Of the others
> that are documented in the --help message, 'jump', 'asm_jump' and 'fast' are
> not tested anywhere near as much as the others and may even be broken; 'hl' is
> slightly slower than 'hlc' and doesn't provide any other benefit;

Agreed.

> 'il' hasn't
> been worked on in years.

Except by Microsoft, who first made incompatible changes in the target
language and then deprecated it :-(

> Modifiers: gc, prof, memprof, profdeep, tr, trseg, spf, stseg, debug,
>             decldebug, par, ssdebug, threadscope, pregen
> 
> * I have long intended to make 'tr' imply 'trseg' and get rid of the latter,
>    so in the long term it will go.

Is there any reason why we cannot NOW add a 'trnoseg' grade component,
and make tr be a synonym for trseg?

> * 'threadscope' seems to spend more time broken than working, but I think
>    Paul still intends to do something with it.

The question is, is it currently useful to people who are not Mercury
developers?

The answer is of course more likely to be "yes" if we target a fixed
version of Threadscope.

> * Users that build the source distribution will obviously encounter the
>    'pregen' grade component but that should be its only use.

Agreed.

> * There is certain class of user, those who write Mercury programs containing
>    significant amounts of C foreign code, for whom the 'll_debug' grades are
>    probably useful, so maybe that component should be included as well?

I am skeptical about that. The help message in the mgnuc script says:

   --low-level-debug
        Enable low-level debugging of the C code. Useful only for Mercury
        system developers.
    -g, --c-debug
        Generate object files that can debugged with C debuggers such as gdb.

The former adds the .ll_debug grade component, but for most people,
the latter would be what they work with. Installing an extra grade just
so that the rest of the Mercury program (including the code of the modules
that you are not interested in) is also compiled with C debugging enabled
seems a bit more than I expect from most people, since they won't be
able to debug (or probably, even to follow) the C code generated by the
Mercury compiler. It is hard enough even for me, and I helped in the
original development :-(

> All other grade components should be removed from user facing documentation.
> That includes, the reference manual and user's guide, the compiler's usage
> message, configure scripts, INSTALL file.  Furthermore, the configure script
> should be modified so that it doesn't automatically select one of the more
> obscure base grades if some of the feature tests fail.
> 
> Provided everyone is happy with the above, it's probably easiest for me to make
> this change.

Modulo the above, I am happy.
 
> There are no objections from me (obviously!).
> For the grade-component options, I suggest the following scheme:
> 
>     --add-grade-component-<feature>
>     --remove-grade-component-<feature>

That would work, but we should also think about shorter names,
such as --add-to-grade and --remove-from-grade, even if they
are not quite as precise.

> For example:
> 
>     --add-grade-component-debug
>     --add-grade-component-decldebug
>     --add-grade-component-parallelism
>     etc

I think the name of the grade component should be accepted
both when spelled out in full (e.g. parallelism) and when abbreviated
(e.g. par).

Zoltan.