[m-rev.] for review: tighten up checks for invlaid grade in mgnuc script etc
jfischer at opturion.com
Thu Apr 23 10:26:36 AEST 2015
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:
>> 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 ;;
>> 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.
More information about the reviews