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

[Julien Fischer]

On Sun, 23 Oct 2005, Ian MacLarty wrote:

> 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.
>
I know but we shouldn't be making large changes to 0.12 that aren't
bugfixes.

> > > 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.
>
My misunderstanding, I thought you were trying to get rid of the shell
scripts.

> > > 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.
>
Thanks (I just wanted to make sure you hadn't forgotten.)

> > > 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).
>
It would be nice if the profiler didn't depend on cygwin as well though.

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