[m-rev.] for review: install executables to top-level bin directory

Julien Fischer juliensf at cs.mu.OZ.AU
Sun Oct 23 22:13:53 AEST 2005


On Sun, 23 Oct 2005, Ian MacLarty wrote:

> This diff is an alternative to my previous proposal of a C version of mmc.
> In this proposal we would install mercury_compile directly to the top-level bin
> directory.  In a subsequent diff I would rename mercury_compile to mmc.
>
> My reasons for abandoning the previous proposal are as follows:
> I encountered some problems with the MinGW version of execv on Windows XP
> (on Windows 98 it seems to work fine).  The MinGW version of execv seems
> to spawn off a new process in the background, instead of replacing the
> current process.  This means control returns to the command shell, even
> though mercury_compile has not yet exited.  Using system instead would
> not be desirable for the reasons pointed out by Peter Moulder.  The C code
> from mmc.c was also quite messy and would be difficult to maintain.
>
> I think this new proposal would be far more elegant.
>
I agree, in any case simplifying the directory structure should help
make Mercury more compatible with package management systems.

> I have tested this change by building and installing Mercury and then using
> the installed compiler to bootcheck the workspace.
>
> I have not yet tested the test_mercury script or the java or il backends,
> but the changes there are small.
>

The Java backend is not an issue, we've never implmented enough of it for
this to be a concern.  I'm not sure about the IL backend and test_mercury
can be fixed easily enough.

> For review by anyone.
>
> Estimated hours taken: 2
> Branches: main and 0.12

I'm happy for this to happen on the main branch, however given that
0.12 has already been released (and 0.12.1 is too far away) I would
prefer not to make changes of this sort to the 0.12 branch.

> Remove the architecture string from the installed directory structure
> and put the executables in $PREFIX/bin, instead of
> $PREFIX/lib/mercury/bin/$FULLARCH.
>
> The reason for this change is to reduce the need for unix shell scripts in
> the top-level bin directory that call the actual programs in the
> lib/mercury/bin/FULLARCH directory.  The unix scripts can't be run on Windows
> without a unix emulation environment like Cygwin.
>
> Because the executables are now in the top-level bin directory, we cannot
> install multiple architectures under the same directory structure.  However
> this is not a real loss, since the binaries for different architectures can
> just be installed to different locations, as we currently do anyway on
> mundula.cs.mu.oz.au.
>
> The plan is to rename mercury_compile to mmc and do away with the mmc unix
> script.

You would need to move the functionality that is currently present in
the mmc, mgnuc and ml scripts into mercury_compile.  That would almost
certainly require changes to mmake (and possibly mmc --make).
(In fact most of what you want is probably already implemented as part
of mmc --make so it's probably just a matter of making mmake understand
it.)

> This will allow mmc to be run on Windows without Cygwin or MSYS.
> This proposal replaces a previous proposal to implement a C version of the
> mmc script.  That solution turned out to be quite complicated and
> unreliable.
>
Could you please commit the library fixes from that diff though.

> This diff will also mean mdice, mslice and mtc_union will be in the same
> directory as mmc, so will be in the PATH as long as mmc is in the PATH.
>
And mercury_profile as well presmably?

I'll continue looking at this tomorrow.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list