[m-users.] Installing a subset of built grades

[Mark Green]

Yes, I do mean the non-C grades. Specifically, the csharp grade seemed to fail due to looking for files in the Windows execution path for the MingW shell rather than in the active directory within MingW. I tried building a new shortcut to start the MingW shell in the Mercury srcdist directory but so far I haven't been able to test it because of the long time taken to get to the csharp grade. 

The Erlang grade fails with a file not found error when building the first beam file. I tried enabling verbose-commands as before; I don't have the log to hand right now, though.

Just to clarify I am talking about restarting an install that failed midway through, not one that was configured with a smaller number of grades. I ran configure and make with all grades enabled but make install failed after installing the C grades. It's really awkward if I really have to just sit and wait while asm_fast.gc etc are built only for the installer to report that all the files are unchanged and just delete all the work it did in the last two hours :( 

Mark

On 29 May 2013, at 06:12, Julien Fischer <jfischer at opturion.com> wrote:

> 
> 
> On Tue, 28 May 2013, Mark Green wrote:
> 
>> I'm currently having some problems compiling the non-native grades of
>> Mercury13.03 on MingW, but the native grades compiled fine (after the
>> first failure I was able to used the successfully installed native
>> grades to bootstrap the next attempts).
> 
> By, "non-native", I assume you mean the non-C grades?  What were the
> problems you encountered?
> 
>> However whenever I try to do the install again, the make script
>> insists on building all of the already-existing native grades, and
>> then goes to install them, generating nothing but a series of
>> "<filename> is unchanged" messages but having spent an hour or more
>> building the grade.  Is there any way to tell the installer which
>> grades to install without reconfiguring the project, or to tell it not
>> to install grades that have already been installed successfully?
> 
> No.  (If you're feeling brave you can hack some Mmakefiles and, after
> installation, edit Mercury.config to conform with any changes, then
> in most circumstances it's possible.)
> 
>> (Perhaps it could store hashes for each successfully installed file in
>> a grade, and if the existing file matches the hash it does not build
>> it again?)
> 
> Fundamentally, the current system is a one shot thing, where the "make
> install" step means install the system + build and install the libraries
> in a bunch of grades.  As currently implemented, it's not designed for
> doing post-installation installation of more library grades.
> 
> Cheers,
> Julien.