<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ross Paterson wrote:
<blockquote cite="mid20050827123414.GA2669@soi.city.ac.uk" type="cite">
<pre wrap="">On Sat, Aug 27, 2005 at 10:38:42AM +0100, Duncan Coutts wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think we just have to accept that windows doesn't understand the #!
thing.
</pre>
</blockquote>
<pre wrap=""><!---->
Indeed. (though the original setting was MinGW+MSYS, not Cygwin)
</pre>
<blockquote type="cite">
<pre wrap="">If fact cabal packages that use configure scripts are not going to be
portable to windows anyway since we cannot assume that users have
MinGW/cygwin installed. That is one of the reasons to favour the simple
cabal build system, because it will work on windows without any unix
utiities like sh & make etc.
</pre>
</blockquote>
<pre wrap=""><!---->
For some packages that interface to C libraries, configure solves a
real problem on Unix systems, and we need a way to solve that problem
on Win32. It might be enough to include Win32 versions of the files
that configure generates, and on Win32 to just copy those instead of
running configure.
</pre>
</blockquote>
I would suggest that, while configure does solve a problem, it isn't
the best way to solve the problem. A properly abstracted and layered
implementation of O/S specific calls, with each environment supported
by an implementation file, is much closer to "doing the right thing."<br>
<br>
It's true that in such a setup many of the implementation files would
be almost identical. I don't see this as a problem; I see it merely as
reflecting the actual situation, which is that the supported
environments are almost identical.<br>
<br>
So I agree with Ross that for win32 we should have a set of interface
files.<br>
<br>
I would also assert that for all supported environments we should have
a set of interface files.<br>
<br>
I did exactly this for an open source project and it worked flawlessly.<br>
<br>
However, people wanted to know why it didn't use configure. If
configure identifies the environment and copies the correct files, that
would satisfy the need for consistency (that is, for this package you
use ./configure just as you do for many other packages). Using the
methodology of configure, in my mind, is embracing ann ugly philosophy.<br>
<br>
I do realize that this position is more or less tilting at windmills.<br>
<br>
Seth<br>
<blockquote cite="mid20050827123414.GA2669@soi.city.ac.uk" type="cite">
<pre wrap="">
_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://www.haskell.org/mailman/listinfo/libraries">http://www.haskell.org/mailman/listinfo/libraries</a>
</pre>
</blockquote>
<br>
</body>
</html>