[m-dev.] Mingw & packaging

[Simon Taylor]

On 10-Nov-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On a related front, how should we deal with packaging the Mingw/Cygwin
> variants?  Should we make Mingw a grade component, and then ship a single
> Mercury distribution for Windows that has two copies of the libraries,
> one for Cygwin and one for Mingw?  That way we could use the Cygwin
> version of the Mercury compiler, which would side-step the path name
> format issue mentioned above.  Users would need to install Cygwin, but
> could easily build applications that don't need Cygwin by just setting
> a Mercury grade option.  (If we make it an option, what should the
> default be -- Mingw or Cygwin?) 

I think Mingw should be the default, because more users are
likely to be interested in creating native applications.

> The main drawback of this approach is that it would increase the size
> (and hence download time) of the distribution significantly, since it
> would double the number of library grades required.
 
> Or should we ship two different distributions for Windows, one for
> Mingw and one for Cygwin?

And one for MSVC, which would hopefully rely on no other external software.

> With this approach, users could pick and
> choose which they wanted to install.  However, users who want both
> would end up with two copies of the compiler, profiler, interface files, etc.

How common would it be for people to want both. My guess would
be that most people would only want the Mingw distribution.

> If we go with this approach, we'd need to either (a) include the
> Cygwin mercury_compile.exe in the Mingw distribution, or (b) fix
> mercury.bat, which seems to have suffered code rot, and eliminate
> the remaining dependencies on Cygwin.

I haven't been updating mercury.bat because I think it's better 
to move all of the configuration stuff into an options file,
to make it easier to use alternative configurations and
to remove the double maintenance problem. I have a change
which does this.

I also have a change which implements ml and c2init in the compiler.
I haven't posted this for review because it moves all of the
C compiler configuration into configure.in, which means that
just setting MERCURY_C_COMPILER is not sufficient to use a
different C compiler with `mmc --make' (it won't know which options
to use to invoke the different compiler). MERCURY_C_COMPILER will
still work with Mmake.

I'm intending to make a change which will make it possible
to generate alternative configurations after installation,
which will eliminate this problem.

Simon.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------