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 #! thing.
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 running configure.
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. Seth
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries