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

[Julien Fischer]

Hi Peter,

On Thu, 23 Apr 2015, Peter Wang wrote:

> On Wed, 22 Apr 2015 15:30:03 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> Hi,
>>
>> On Wed, 22 Apr 2015, Peter Wang wrote:
>>
>>> On Wed, 22 Apr 2015 11:26:35 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>>>> +
>>>> +#
>>>> +# .profdeep grades are not compatible with high-level code
>>>> +#
>>>> +case $highlevel_code,$profile_deep in true,true)
>>>> +	echo "--high-level-code and --profile-deep are not compatible" 1>&2
>>>> +	exit 1 ;;
>>>> +esac
>>>
>>> --deep-profiling
>>
>> Fixed.  Actually, --deep-profiling is what mmc uses, --profile-deep is
>> what the mgnuc script uses :-(
>>
>> The mgnuc script (and canonical_grade etc) could do with further
>> clean-ups if anyone is interested in taking a look at it.  In
>> particular, they should really reject an attempt to specify two base
>> grades, for example "csharp.erlang".
>
> Hardly anyone would be using those scripts any more, would they?

By choice, I suspect not, but anyone building Mercury from the source
distribution will end up indirectly using mgnuc and the configure script
will use the canonical_grade script (if it exists) to check that grades
supplied by the user (e.g. as arguments to --enable-libgrades) are
valid. (Or at least as valid as it can currently determine.)

One other change I think would be worth making is that the 'realclean'
target should not delete the canonical_grade script (only the
'distclean' target should do that).  This would mean that the grade
validity check still works after do a realclean.  This is useful
because we recommend that users do a realclean when re-compiling after
installing the source distribution.

> and its helpers out of the user guide and into a separate document;
> I think we can reduce confusion by moving the documentation for mmake

Agreed.   The main reason I think we haven't done that is (1) the
replacement documentation for "mmc --make" is not really up to scratch
and (2) a lot of the documentation for "mmc --make" is tangled up with
that of mmake.

> and, to a lesser degree, moving the helper scripts out of the main bin
> directory and into lib/mercury/bin or something.

I have an alternative suggestion, which is that we simply don't install
mmake (and its associated dependencies) by default.

Cheers,
Julien.