[m-dev.] New release?

[Julien Fischer]

Hi Mark,

On Mon, 26 Oct 2015, Mark Brown wrote:

> On Mon, Oct 26, 2015 at 10:49 AM, Julien Fischer <jfischer at opturion.com> wrote:
>>
>> Hi Zoltan,
>>
>> On Thu, 22 Oct 2015, Zoltan Somogyi wrote:
>>> At the moment, we have three pieces of code for computing the grade from
>>> options. The Mercury version of this code is used by the compiler, and is
>>> now in compiler/compute_grade.m. The C version, used by e.g. mgnuc and ml,
>>> is in scripts/*_grade.sh-subr. The algorithm above is too complex to
>>> implement
>>> in sh, so I propose that it be put into a small library containing nothing
>>> but the code that takes a list of grade-related options, and returns
>>> the selected solution of the constraint problem they represent. The code
>>> of compute_grade.m would invoke this small library, and so would a new
>>> standalone Mercury program, named e.g. compute_grade_for_sh.m, that
>>> would be invoked from a new sh script, named e.g. compute_grade.sh-subr.
>>
>> Won't this be a problem when building from the source distribution since the
>> small Mercury program would need to be compiled from the pre-generated .c
>> files
>> and doing so requires both the mgnuc and ml scripts?
>
> The scripts will only really need to call this program if high-level
> options for selecting the grade are actually used. If the grade is
> given explicitly and in canonical form then that won't be needed, so
> in this case the scripts can be run before the program is built.
>
> So configure would have two jobs:
> - Without using the compute_grade library, figure out a single grade
> that will definitely work and can be used to build the compute_grade
> library and the standalone programs. This would surely be the same
> grade as will be used to build the compiler.

It will necessarily have to be that grade ;-)  You won't have a runtime
or standard library to link it against otherwise.

> - Determine the platform dependent constraints that the compute_grade
> library would use.
>
>> Also, in the source
>> distribution we ideally want the canonical_grade script to be available so
>> that
>> if the user supplies a list of grades to configure (e.g. via
>> --enable-libgrades), we can sanity check them when configure is run.
>
> The sanity checks could be done at the start of the make step, which
> is not that much later than currently.

Ideally not, since that introduces a disconnect between the action of
running ./configure and the point at which you get the error message.

>>> The latter would replace the existing script/*grade.sh-subr, and probably
>>> also scripts/canonical grade. The third copy is in
>>> runtime/mercury_grade.h,
>>> and it will continue to need double maintenance with the Mercury code.
>>>
>>> If the use of a Mercury by e.g. canonical_grade would be a problem,
>>> we could try continuing to use sh code to compute the grade. The algorithm
>>> above should *just about* be doable in sh, even though it would not be
>>> pretty sight.
>>
>>
>> mmc (when invoked by itself) and mmc --make require will the new grade
>> related
>> machinery, since they are what we are intend end users of the system to use.
>> I don't think we need to do anything with mgnuc / ml (mmake), since at this
>> point they are primarily tools for building the Mercury system itself.
>
> They will need to be able to compile in the grade determined by
> configure for compiling the compiler, compute_grade library, and the
> standalone programs. The "double maintenance" issue is that this
> grade, on all platforms, has to be the same one that is selected via
> an unconstrained search using the new method. Everything else will go
> via the compute_grade library.
>
> Does that address your reservations?

I have two issues here:

1.  Should you be able to use the new method of specifying a grade when
building the Mercury system itself?  I'm saying no: for the source
distribution you don't have a choice of grade**, non-developers are better
off going with what configure decides and developers ought to know how
to specify a grade directly.

(** these days it must be hlc.gc.pregen)

2.  Do we continue to support mmake (and its attendent shell scripts) as
a user level feature (as opposed to just something that builds the
Mercury system)?  If not, then we don't need to support the new method
with them.  (Note that mmake already lacks many features that mmc --make
has, in addition to its documented problems with sub-modules etc.)

Julien.