[m-dev.] New release?

[Mark Brown]

Hi Julien,

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.
- 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.

>
>> 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?

Cheers,
Mark.