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

[Paul Bone]

On Thu, Sep 18, 2014 at 01:50:52AM +1000, Julien Fischer wrote:
>
> On Tue, 16 Sep 2014, Zoltan Somogyi wrote:
>
>>
>> On Tue, 16 Sep 2014 14:57:18 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>>
>>> More generally, I think the are quite a few problems with grade
>>> components.  Of the top of my head:
>>>
>>> (1) Too many experimental or not-useful grade components are currently
>>> documented at the user-level, for example agc, hl, il, hgc, jump, fast.
>>
>> Do you want to post a list of the grade components,
>> and whether you think they should be exposed to users?
>
> 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; 'il' hasn't
> been worked on in years.
>
> 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.
> * 'threadscope' seems to spend more time broken than working, but I think
>   Paul still intends to do something with it.

Yes I do.  Also this is a work-related priority too so it's likely to
get more attention than some of my other Mercury related tasks.

> * Users that build the source distribution will obviously encounter the
>   'pregen' grade component but that should be its only use.
> * 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?
>
> 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.

Can we make debug imply decldebug and remove the explicit "decldebug" grade
modifier?  To say it another way, if I want a debugging grade is it ever
"bad" to add the declrative debugging features?

Similarly, I think that the par grade component on the low level C backend
should always imply the stseg grade component.  And AFAIK it's rare that
someone would want the stseg feature in a non-parallel build.  This would
allow us to make the stseg grade component a developer-only option, maybe
with a breif note next to the parallel grade's documentation.


>> I suggest adding alternate names for --debug, --trailing etc, names
>> that mention that these are grade components, names that
>> all follow the same template. For a while, we can encourage people
>> to use those instead of the old option names. We can also add
>> new options that do what people expect from the old options,
>> with their names following another, distinct naming scheme.
>> After a period of adjustment, we can change the old option
>> names to be synonyms of the 'choose-the-best' options,
>> not the 'grade-component' options.
>>
>> Any objections, or opinions about what these naming schemes
>> should be?
>
> 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>
>
> For example:
>
>    --add-grade-component-debug
>    --add-grade-component-decldebug
>    --add-grade-component-parallelism
>    etc
>

Fine with me.

Thanks.

-- 
Paul Bone