[m-dev.] New release?

[Julien Fischer]

Hi Mark,

On Wed, 21 Oct 2015, Mark Brown wrote:

> On Wed, Oct 21, 2015 at 11:14 AM, Julien Fischer <jfischer at opturion.com> wrote:
>> On Wed, 21 Oct 2015, Paul Bone wrote:
>>> On Wed, Oct 21, 2015 at 10:25:57AM +1100, Julien Fischer wrote:
>>>> There was a list of things we wanted to do to address the "too many
>>>> grades"
>>>> problem.  Some of these have been done (e.g. hiding user facing
>>>> documentation
>>>> for experimental grade components), others haven't yet (e.g. merging the
>>>> 'tr'
>>>> and 'trseg' grade components and renaming the grade component options).
>>>> See
>>>> the following thread:
>>>>
>>>> <http://www.mercurylang.org/list-archives/reviews/2014-September/017297.html>
>>>
>>>
>>> When this came up recently Micheal (despite how he raised the issue) made
>>> a
>>> good suggestion that we should document not just what the grade components
>>> mean (which mostly exists in the user guide) but which combinations make
>>> sense / are supported / are well tested.
>
> This doesn't address the key problem, which is that users need to know
> anything at all about what the grade components mean when they are
> installing Mercury. We know the common use cases for installation;
> most users should only have to pick which one they want. E.g.:
>
> - user who wants to compile some code they have found

That rather depends on what code they have "found" ;-)

Even in the absence of things like debugging and profiling that may be
quite few grades.

> - developer who wants profilers, debugger, etc
> - developer who knows exactly the set of grades they want
> - sysad who wants everything because they don't want to be bothered by
> follow-up requests
> - user who wants to bootstrap from ROTD
>
> The configure script ought to be able to decide the set of grades
> based on this choice, perhaps with some additional tweaks available.

We could add a new configure option to select a (mostly) pre-determined
set of grades, for example:

    --with-installation-profile = {default,debug,all,minimal}

where the profile names correspond to the the first, second, fourth
and fifth cases above.  (The above names are for illustration only,
I realise they're not great.)

The second point is handled by the existing '--enable-libgrades' option.

To an extent this just shifts the problem around, "what grades do I
install" becomes "what profile to I select"?

Julien.