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

Ian MacLarty maclarty at cs.mu.OZ.AU
Sun Oct 23 23:12:47 AEST 2005


On Sun, 23 Oct 2005, Julien Fischer wrote:

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

I wanted to apply it to the 0.12 branch so we could release a
Cygwin-independent Windows binary package for 0.12.

> > The plan is to rename mercury_compile to mmc and do away with the mmc unix
> > script.
>

I shouldn't have said I wanted to "do away" with the mmc script.  I meant to
say that mercury_compile would be installed to the bin directory with the name
mmc.  The mmc script would still be used for bootchecking and in the build
process.

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

Why do I need to move the mgnuc and ml functionality into mercury_compile?

The only extra thing mercury_compile would need to do would be to resolve
MERCURY_CONFIG_DIR.  In the usual case where this is known at configure time
this will be achieved by defining the appropriate symbols in mercury_conf.h.
In the standalone case we could require the MERCURY_COMPILER environment
variable to be set and then mercury_compiler would make the configuration
directory, C compiler and linker paths relative to that directory.  On Windows
the installer could automatically set the MERCURY_COMPILER environment variable
at install time.  This would be much simpler and more reliable than trying to
find out where the mercury_compiler executable is being run from.

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

I already have ;-).  Since they were already reviewed I didn't post the diff.

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

Yes, although that already has a forwarding script (mprof).

> I'll continue looking at this tomorrow.
>

Cheers,

Ian.

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