[mercury-users] Mercury for Win32 under Visual C? Was: Re: Mercury for Mac ?

[Alexander Voinov]

Dear Colleagues,

> Peter Moulder, you wrote:
> > On Fri, 7 Nov 1997, Fergus Henderson wrote:
> > 
> > > If you can get a vaguely Unix-like environment (i.e. gcc, make, sh, and a
> > > few others) under MacOS, then it would not be too hard.
> > 
> > So far, Mercury has avoided gcc dependencies, hasn't it?  (Though I know 
> > it does benefit from having gcc extensions present, in terms of efficiency.)
> > 
> > If one just wanted a bare-bones Mercury environment (no Mmake), wouldn't 
> > any ANSI C environment suffice, so long as someone in a Unix environment 
> > compiles the Mercury compiler to ANSI C output?
> 
> Yes.  But a bare-bones Mercury environment would be fairly bare.
> Although the compiler itself needs only ANSI C, quite a bit of the
> infrastructure basically assumes a Unix-like (or POSIX) environment.
> To start with, we use an autoconf configuration script, so for a
> non-Unix environment, you'd need to configure it by hand.
> And `mmc', `ml', `mgnuc', `mercury_update_interface', etc. are all shell
> scripts.  You'd need to reimplement those (they total about 1000 lines or so).
> Also the Mercury compiler is itself built using Mmake, and although you
> could build it by hand, that would be a bit of a hassle.
> When all's said and done I think it would just be much less hassle
> for greater benefit to use something like MachTen, at least for
> building Mercury from the source code.  You could perhaps then create a
> binary release for Mac which didn't need MachTen.
> 
> > I don't know whether the libraries assume POSIX, and I suppose that 
> > filesystem access (esp. `/' vs. `:' vs. `\') would need changes.
> 
> The Mercury libraries mostly assume only ANSI C,
> but there are some places in the runtime that make use of some POSIXisms.
> I think mostly it is done with conditional compilation, so it shouldn't
> be too hard, but it would probably require a bit of effort.
> 
> The pathname-dependent code is mostly in the shell scripts and the
> compiler's Mmake files; as for `/' vs `:' vs `\', in the Mercury code
> I think only one predicate in the library (dir__directory_separator/1)
> should need changing.

And what about the situation when a Mercury module should be incorporated
into existing Visual C/MFC based code?
What is better?
1. To port this application to gnu-win32 (with or without MFC)?
   This way, e.g. the absence of precompiled headers makes gcc very tedious 
   to work with large C++ libraries.
2. To tune Mercury win32 port to become friendly to Visual C at least at
   the last stage -- generation of code?

Is the second item implemented by anyone in Mercury community?

Regards
Alexander