"#!..." (Re: cabal configure screw-up)
seth at cql.com
Sat Aug 27 09:02:12 EDT 2005
Ross Paterson wrote:
>On Sat, Aug 27, 2005 at 10:38:42AM +0100, Duncan Coutts wrote:
>>I think we just have to accept that windows doesn't understand the #!
>Indeed. (though the original setting was MinGW+MSYS, not Cygwin)
>>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.
>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
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."
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.
So I agree with Ross that for win32 we should have a set of interface files.
I would also assert that for all supported environments we should have a
set of interface files.
I did exactly this for an open source project and it worked flawlessly.
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.
I do realize that this position is more or less tilting at windmills.
>Libraries mailing list
>Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries