[m-dev.] Mingw & packaging

Fergus Henderson fjh at cs.mu.OZ.AU
Sun Nov 10 03:03:01 AEDT 2002


After Simon's fix for the problem with pid_t, the compiler now compiles
and installs fine on Cygwin when configured with CC="gcc -mno-cygwin".
This option causes GCC to (cross-) compile to a native Windows executable,
using Mingw, rather than compiling to an executable that uses the Cygwin
Unix emulation library.

However, using the resulting compiler is not so easy, since the compiler
uses Windows path names, but the scripts which invoke it assume Unix
path names.

One way to solve it is to use the mercury_compile.exe file from
a compiler built with Cygwin, but use the libraries built with Mingw.

Pete, how do you deal with this issue when compiling with MSVC?



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

Maybe we should go even further, and split the distribution into
smaller parts:

	- base part (compiler, scripts, etc.)
	- documentation (some users may prefer to browse the
	  documentation on the web rather than downloading it)
	- debugger
	- profiler
	- deep profiler
	- libraries
		which could be further divided into those which target
		- Cygwin
		- Mingw
		- .NET
		or we could even distribute each grade separately

But this would make installation more difficult, unless we have some
tool that lets users select what configuration they want and then
automatically downloads and installs all the parts needed for that
configuration.


Any suggestions / comments?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list