[m-users.] Installing a subset of built grades
p0073857 at brookes.ac.uk
Wed May 29 22:25:28 AEST 2013
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 :(
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.
More information about the users