How to install HOpenGL to Windows?
I get darcs source HOpenGL Try runghc Setup.hs configure I see: Configuring OpenGL-2.3... Warning: The 'build-type' is 'Configure' but there is no 'configure' script. Setup.hs: configure script not found. runghc Setup.hs build wrote: Preprocessing library OpenGL-2.3... Building OpenGL-2.3... Graphics\Rendering\OpenGL\GL\BasicTypes.hs:24:0: HsOpenGLConfig.h: No such file or directory How to build HOpenGL? Os Windows Vista Home Ru + sp ghc 6.10.1
On Wed, Apr 8, 2009 at 3:14 PM, Alexandr N. Zamaraev
How to build HOpenGL?
Os Windows Vista Home Ru + sp
Hello Alexandr, Linked from here http://www.haskell.org/haskellwiki/Opengl http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ Jeff
1) install "cabal-install". download this filehttp://www.haskell.org/cabal/release/cabal-install-0.6.2/cabal.exe and put it in a directory in your %PATH% 2) to compile most libraries on Hackage that link to C libraries via the FFI, you need to install MinGW and MSYS, as Jeff said explained herehttp://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ (many thanks to David Sankel for taking the time to write this). After you installed this, you have UNIX like environment and the GNU C compiler suite. 3) start MSYS, and type "cabal install opengl". This will download, configure, build and install opengl from hackage. this works for me. Instead of GLUT you can also use GLFW; the install this, just type "cabal install GLFW" On Wed, Apr 8, 2009 at 7:14 AM, Alexandr N. Zamaraev < tonal.promsoft@gmail.com> wrote:
I get darcs source HOpenGL Try runghc Setup.hs configure I see: Configuring OpenGL-2.3... Warning: The 'build-type' is 'Configure' but there is no 'configure' script. Setup.hs: configure script not found.
runghc Setup.hs build wrote: Preprocessing library OpenGL-2.3... Building OpenGL-2.3...
Graphics\Rendering\OpenGL\GL\ BasicTypes.hs:24:0: HsOpenGLConfig.h: No such file or directory
How to build HOpenGL?
Os Windows Vista Home Ru + sp ghc 6.10.1 ______________________________ _________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Verswyvelen ha scritto:
1) install "cabal-install". download this file http://www.haskell.org/cabal/release/cabal-install-0.6.2/cabal.exe and put it in a directory in your %PATH%
2) to compile most libraries on Hackage that link to C libraries via the FFI, you need to install MinGW and MSYS, as Jeff said explained here http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ (many thanks to David Sankel for taking the time to write this). After you installed this, you have UNIX like environment and the GNU C compiler suite.
3) start MSYS, and type "cabal install opengl". This will download, configure, build and install opengl from hackage.
this works for me.
This is an overkill, really. IMHO, there should be no need to install an UNIX like environment on Windows. The problem, here, is that packages use autoconf. This should be avoided; instead Cabal should support some simple features for packages configuration. http://hackage.haskell.org/trac/hackage/ticket/530 Does HOpenGL really need all the features of autoconf?
[...]
Regards Manlio
Yes I totally agree that it is overkill. Ideally I would like every package
to install on Windows without requiring MinGW. But I was just explaining the
situation as it is right now.
On Wed, Apr 8, 2009 at 10:31 PM, Manlio Perillo
Peter Verswyvelen ha scritto:
1) install "cabal-install". download this file < http://www.haskell.org/cabal/release/cabal-install-0.6.2/cabal.exe> and put it in a directory in your %PATH%
2) to compile most libraries on Hackage that link to C libraries via the FFI, you need to install MinGW and MSYS, as Jeff said explained here < http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/> (many thanks to David Sankel for taking the time to write this). After you installed this, you have UNIX like environment and the GNU C compiler suite.
3) start MSYS, and type "cabal install opengl". This will download, configure, build and install opengl from hackage.
this works for me.
This is an overkill, really. IMHO, there should be no need to install an UNIX like environment on Windows.
The problem, here, is that packages use autoconf. This should be avoided; instead Cabal should support some simple features for packages configuration.
http://hackage.haskell.org/trac/hackage/ticket/530
Does HOpenGL really need all the features of autoconf?
[...]
Regards Manlio
Am Donnerstag, 9. April 2009 00:28:35 schrieb Peter Verswyvelen:
Yes I totally agree that it is overkill. Ideally I would like every package to install on Windows without requiring MinGW. But I was just explaining the situation as it is right now.
Well, I don't like using autoconf, either, but currently I don't see an alternative. If you look at the configure.ac of the OpenGL package, you can see that autoconf has to figure out the following: * How to link programs using OpenGL * The Haskell types corresponding to the OpenGL types * To do the former: How to find the OpenGL C headers * The library calling convention * How to load OpenGL extensions The build process in itself is purely Cabal-based, it is only the configuration above which done via autoconf. So in theory you could write the few output files of the configure run by hand and then use Cabal, without any MinGW/MSYS or cygwin. I don't see how Cabal could help here even further, the tests above are quite OpenGL-specific, but I am open for suggestions. Cheers, S.
On Sun, 2009-04-26 at 19:03 +0200, Sven Panne wrote:
The build process in itself is purely Cabal-based, it is only the configuration above which done via autoconf. So in theory you could write the few output files of the configure run by hand and then use Cabal, without any MinGW/MSYS or cygwin.
I don't see how Cabal could help here even further, the tests above are quite OpenGL-specific, but I am open for suggestions.
Cabal packages allow some configuration to be done in the Setup.hs however the Cabal library does not provide much in the way to help you do the kinds of test that you need to do (esp compared to the large lib of macros that autoconf provides). What I'd like someone to do is to investigate what tests we'd need to provide that would allow us to eliminate which ./configure scripts. http://hackage.haskell.org/trac/hackage/ticket/482 I want an answer like: "If we implement these 5 tests then we can cover enough functionality to eliminate the ./configure script in these 10 packages. If we add these 3 extra then we can eliminate a further 5 ./configure scripts." Sven, perhaps you can contribute to this task by noting in slightly more detail what tests we'd need to do in the Setup.hs to eliminate the ./configure script for OpenGL and what support you'd want from the Cabal library to do so. The above bullet points are a good start but we probably want slightly more detail. Let me start with some naive suggestions and perhaps you can fill in the details:
* How to link programs using OpenGL
This is because the GL libs are called different names on different platforms right? But they're consistent within each platform, it's just Windows vs everyone else isn't it? How about: if os(windows) extra-libraries: gl32 else extra-libraries: GL
* The Haskell types corresponding to the OpenGL types
Does hsc2hs #type not help us with this? (I would also suggest c2hs but that would be a much bigger change in the binding.)
* To do the former: How to find the OpenGL C headers
What's needed here? Are they not in standard locations? Cabal has support for users to specify non-standard locations.
* The library calling convention
This is stdcall on Windows and ccall everywhere else right? How about: if os(windows) cpp-options: -DCALLCONV=stdcall else cpp-options: -DCALLCONV=ccall
* How to load OpenGL extensions
I don't know enough of the details here to comment. Duncan
Am Montag, 27. April 2009 00:11:20 schrieb Duncan Coutts:
On Sun, 2009-04-26 at 19:03 +0200, Sven Panne wrote: [...]
* How to link programs using OpenGL
This is because the GL libs are called different names on different platforms right? But they're consistent within each platform, it's just Windows vs everyone else isn't it?
How about:
if os(windows) extra-libraries: gl32 else extra-libraries: GL
As usual, things are always a bit trickier than they appear initially: On non- Windows systems it is not always sufficient to link against libGL alone, sometimes you'll have to link against several X11 libs, too. I am not sure if this is still a widespread problem, but in the past it was. Hopefully most *nices get their dynamic library dependencies right nowadays... :-P Windows is, as always, a special beast, especially when you take Cygwin into account: On Cygwin you can either build against the native OpenGL or against Cygwin's X11 OpenGL. This can be configure via --without-x. How can we do this in .cabal files? And MacOS had some peculiarities which I can't fully remember anymore, too.
* The Haskell types corresponding to the OpenGL types
Does hsc2hs #type not help us with this? [...]
I am not sure, because I haven't had a look at hsc2hs for a long time, and at the beginning of the OpenGL binding there were no such tools, not even the FFI in its current form. Perhaps I'll have a look at this, but to make this work, I am sure that we'll have to solve the next item:
* To do the former: How to find the OpenGL C headers
What's needed here? Are they not in standard locations? Cabal has support for users to specify non-standard locations.
What is a "standard location" for headers on Windows? There is no such concept. On *nices you look into /usr/include and /usr/local/include, and that's it, unless the user tells you something different. And Apple is always a very creative company, so they decided to put *their* OpenGL headers in a completely different path where no -I flag can help... Having access to the OpenGL headers is crucial for finding out which C types are behind OpenGL types like GLint, GLenum, ... The OpenGL spec only specifies minimum requirements for these types and *not* their C mapping.
* The library calling convention
This is stdcall on Windows and ccall everywhere else right?
How about:
if os(windows) cpp-options: -DCALLCONV=stdcall else cpp-options: -DCALLCONV=ccall
This should be fine, at least when we solve the Cygwin problem discussed above: The X11 OpenGL libraries on Windows do *not* use stdcall, only the native OpenGL libraries. (The whole calling convention story on Windows really, really sucks, IMHO...) Using CPP for this simple task doesn't look right, but with the current FFI I don't see a way around this, which is a shame. Any ideas/proposals for a FFI change?
* How to load OpenGL extensions
I don't know enough of the details here to comment.
You'll have to know if wglGetProcAddress, NSAddressOfSymbol (+ a bit more code) or some variant of glXGetProcAddress has to be used, plus their necessary headers. This is probably doable via some platform switches in Cabal, too. A few general remarks: * Ignoring the (usual) Windows trouble, I like autoconf's approach of testing features instead of relying on extremely fragile platform conditionals. The latter are a constant source of troubles and from a SW engineering point of view, they are a clear step backwards. The "I know my platform" approach which you basically propose reminds me of the xmkmf hell from the last millennium: If X11 didn't know your platform, you had a *lot* of fun getting the platform description right. * We can go this autoconf-free route, but this is a part of my bindings which I definitely won't maintain in full time. I'll be happy to review and accept patches, but making things work on Windows, Cygwin, Linux, *BSD, MacOS X, ... is a lot of work, which is a fact I have painfully learned in the past few years. The autoconf code may be ugly, but the tons of platform differences are ugly, to. I want to work on the binding itself mainly, not on the build system, which currently works. To repeat myself: Patches are happily accepted, but I propose incremental changes and heavy testing on various platforms. * Most of the tasks my autoconf scripts perform are not specific to OpenGL at all. I guess that most bindings for non-trivial C libraries face the same challenges (Where are my libs? Where are my headers? What are my types?) Having good Cabal support for these would be very nice. Cheers, S.
On Mon, 2009-04-27 at 19:03 +0200, Sven Panne wrote:
Am Montag, 27. April 2009 00:11:20 schrieb Duncan Coutts:
On Sun, 2009-04-26 at 19:03 +0200, Sven Panne wrote: [...]
* How to link programs using OpenGL
This is because the GL libs are called different names on different platforms right? But they're consistent within each platform, it's just Windows vs everyone else isn't it?
How about:
if os(windows) extra-libraries: gl32 else extra-libraries: GL
As usual, things are always a bit trickier than they appear initially: On non- Windows systems it is not always sufficient to link against libGL alone, sometimes you'll have to link against several X11 libs, too. I am not sure if this is still a widespread problem, but in the past it was.
Right. It's still possible to use custom code in Setup.hs to test these kinds of things. It's a bit less easy however.
Hopefully most *nices get their dynamic library dependencies right nowadays... :-P Windows is, as always, a special beast, especially when you take Cygwin into account: On Cygwin you can either build against the native OpenGL or against Cygwin's X11 OpenGL. This can be configure via --without-x. How can we do this in .cabal files? And MacOS had some peculiarities which I can't fully remember anymore, too.
I didn't know that there was any working GHC for Cygwin. Or do you mean building a non-cygwin lib but under the cygwin shell?
* The Haskell types corresponding to the OpenGL types
Does hsc2hs #type not help us with this? [...]
I am not sure, because I haven't had a look at hsc2hs for a long time, and at the beginning of the OpenGL binding there were no such tools, not even the FFI in its current form. Perhaps I'll have a look at this, but to make this work, I am sure that we'll have to solve the next item:
* To do the former: How to find the OpenGL C headers
What's needed here? Are they not in standard locations? Cabal has support for users to specify non-standard locations.
What is a "standard location" for headers on Windows? There is no such concept.
Right, there's just the includes that come with ghc's bundled version of mingw. Cabal knows how to find them because they're listed as an include dir for the rts package I think.
On *nices you look into /usr/include and /usr/local/include, and that's it, unless the user tells you something different. And Apple is always a very creative company, so they decided to put *their* OpenGL headers in a completely different path where no -I flag can help...
But you have some way of finding them right? Even if it's platform dependent. We can do the same in the .cabal file or the Setup.hs. There's also a Cabal flag users can pass to tell us about extra lib and include dirs.
Having access to the OpenGL headers is crucial for finding out which C types are behind OpenGL types like GLint, GLenum, ... The OpenGL spec only specifies minimum requirements for these types and *not* their C mapping.
Absolutely, finding headers is important. Cabal now checks at configure time that all header files and libs listed in the .cabal file can actually be found.
* The library calling convention
This is stdcall on Windows and ccall everywhere else right?
How about:
if os(windows) cpp-options: -DCALLCONV=stdcall else cpp-options: -DCALLCONV=ccall
This should be fine, at least when we solve the Cygwin problem discussed above: The X11 OpenGL libraries on Windows do *not* use stdcall, only the native OpenGL libraries. (The whole calling convention story on Windows really, really sucks, IMHO...) Using CPP for this simple task doesn't look right, but with the current FFI I don't see a way around this, which is a shame. Any ideas/proposals for a FFI change?
One suggestion I've seen is just to improve the ffi pre-processors. The c2hs tool is in a position to discover if the calling convention is stdcall or ccall so it could generate the foreign imports correctly.
* How to load OpenGL extensions
I don't know enough of the details here to comment.
You'll have to know if wglGetProcAddress, NSAddressOfSymbol (+ a bit more code) or some variant of glXGetProcAddress has to be used, plus their necessary headers. This is probably doable via some platform switches in Cabal, too.
A few general remarks:
* Ignoring the (usual) Windows trouble, I like autoconf's approach of testing features instead of relying on extremely fragile platform conditionals. The latter are a constant source of troubles and from a SW engineering point of view, they are a clear step backwards. The "I know my platform" approach which you basically propose reminds me of the xmkmf hell from the last millennium: If X11 didn't know your platform, you had a *lot* of fun getting the platform description right.
Honestly, I've not resolved in my mind which approach is better yet. I can see the advantages of the feature tests over static per-platform configurations. On the other hand, declaring packages dependencies (in as much detail as necessary) has great advantages too in terms of automating package management. I'm still looking for a solution that combines the advantages of both. In practise I've not found that most configure scripts actually do feature based tests. There's some, but half of it degenerates into "if we've not got the OSX framework for this then do that". I mean they just end up doing platform-specific conditionals. In the mean time I expect we get a reasonable solution by moving as far as possible the tests into the .cabal and Setup.hs scripts. That would make building on Windows a good deal less painful and it'll let us see clearly what we can provide in Cabal to simplify the Setup.hs scripts.
* We can go this autoconf-free route, but this is a part of my bindings which I definitely won't maintain in full time. I'll be happy to review and accept patches, but making things work on Windows, Cygwin, Linux, *BSD, MacOS X, ... is a lot of work, which is a fact I have painfully learned in the past few years. The autoconf code may be ugly, but the tons of platform differences are ugly, to. I want to work on the binding itself mainly, not on the build system, which currently works. To repeat myself: Patches are happily accepted, but I propose incremental changes and heavy testing on various platforms.
* Most of the tasks my autoconf scripts perform are not specific to OpenGL at all. I guess that most bindings for non-trivial C libraries face the same challenges (Where are my libs? Where are my headers? What are my types?) Having good Cabal support for these would be very nice.
Cabal does now support the common simple case of checking that libs and headers are found (when they're declared in the .cabal file). The types one is probably better dealt with by an FFI preprocessor or possibly just using the FFI libs directly (sizeOf function), but perhaps could be done with help from Cabal. Anyway, so that's why I'd like us to look in detail at what features we need in Cabal to let us switch most packages from using ./configure scripts to using Setup.hs scripts. Duncan
Am Mittwoch, 29. April 2009 11:25:31 schrieb Duncan Coutts:
On Mon, 2009-04-27 at 19:03 +0200, Sven Panne wrote:
[...] As usual, things are always a bit trickier than they appear initially: On non- Windows systems it is not always sufficient to link against libGL alone, sometimes you'll have to link against several X11 libs, too. I am not sure if this is still a widespread problem, but in the past it was.
Right. It's still possible to use custom code in Setup.hs to test these kinds of things. It's a bit less easy however.
That's why the autoconf macros are so tricky. Re-inventing the wheel in Haskell is not something I'd like to do. Note: I see autoconf as a necessary evil, not as a glorious tool. The predefined autoconf macros contain man years (if not man decades) of sweat and tears from people trying to make their SW portable. If you only know 1 or 2 platforms, everything looks easy, but this is not the case at all. Good luck for everybody trying to ignore that accumulated knowledge...
I didn't know that there was any working GHC for Cygwin. Or do you mean building a non-cygwin lib but under the cygwin shell? [...]
I don't know if GHC currently builds under Cygwin, but in former times it was *the* way (read: one and only way) to build it on Windows.
On *nices you look into /usr/include and /usr/local/include, and that's it, unless the user tells you something different. And Apple is always a very creative company, so they decided to put *their* OpenGL headers in a completely different path where no -I flag can help...
But you have some way of finding them right? Even if it's platform dependent. We can do the same in the .cabal file or the Setup.hs. There's also a Cabal flag users can pass to tell us about extra lib and include dirs.
I even have standard, well-documented, platform-independent way: Tell configure about it via the environment variable CPPFLAGS for headers and LDFLAGS for libraries. Cabal is buggy in this respect, IIRC, it passes no or incorrectly named variables to configure.
Absolutely, finding headers is important. Cabal now checks at configure time that all header files and libs listed in the .cabal file can actually be found.
I don't know what Cabal does internally, but simply checking for the existence of a header file or a library file is *far* too naive, look into the autoconf docs and/or mailing lists to see why. You actually have to compile for header checks and link for library checks, everything else is plainly wrong, because you'll probably miss dependencies, pick up the wrong stuff, etc.
One suggestion I've seen is just to improve the ffi pre-processors. The c2hs tool is in a position to discover if the calling convention is stdcall or ccall so it could generate the foreign imports correctly. [...]
This wouldn't help much: The foreign imports in OpenGL are written by hand, and when the OpenGL ARB ever manages to release some consistent, machine- usable and complete API description (the current .spec files fail in almost all these aspects), they will be generated from that, not from C headers, because, not surprisingly, the latter lack a lot of information.
In practise I've not found that most configure scripts actually do feature based tests. There's some, but half of it degenerates into "if we've not got the OSX framework for this then do that". I mean they just end up doing platform-specific conditionals. [...]
This is often correct for hobby projects of inexperienced people, but not necessarily for larger or more mature projects. And in a (very) few cases, platform-specific conditionals are even the right thing to do, but not in the vast majority of cases, of course. And this has nothing to say about autoconf itself: Seeing e.g. ugly Haskell code is not a reason to condemn Haskell itself, either.
Anyway, so that's why I'd like us to look in detail at what features we need in Cabal to let us switch most packages from using ./configure scripts to using Setup.hs scripts.
As I said in another email: I'll happily review and accept patches for this, but I won't spend any effort on re-inventing the autoconf wheel in Haskell. Cheers, S.
On Thu, 2009-04-30 at 19:44 +0200, Sven Panne wrote:
That's why the autoconf macros are so tricky. Re-inventing the wheel in Haskell is not something I'd like to do. Note: I see autoconf as a necessary evil, not as a glorious tool. The predefined autoconf macros contain man years (if not man decades) of sweat and tears from people trying to make their SW portable. If you only know 1 or 2 platforms, everything looks easy, but this is not the case at all. Good luck for everybody trying to ignore that accumulated knowledge...
The thing is, it doesn't really matter if autoconf macros work fine for every Unix ever invented. The Windows users simply cannot use packages with configure scripts. They complain about it a lot. We can call them foolish for not installing cygwin/mingw, but they will not do it and instead will simply not use our software and/or continue to complain.
But you have some way of finding them right? Even if it's platform dependent. We can do the same in the .cabal file or the Setup.hs. There's also a Cabal flag users can pass to tell us about extra lib and include dirs.
I even have standard, well-documented, platform-independent way: Tell configure about it via the environment variable CPPFLAGS for headers and LDFLAGS for libraries. Cabal is buggy in this respect, IIRC, it passes no or incorrectly named variables to configure.
Right then lets fix it, lets work out exactly which flags or env vars to pass. See: http://hackage.haskell.org/trac/hackage/ticket/458 Doing it is not hard, it's working out exactly what to pass that's the important matter.
Absolutely, finding headers is important. Cabal now checks at configure time that all header files and libs listed in the .cabal file can actually be found.
I don't know what Cabal does internally, but simply checking for the existence of a header file or a library file is *far* too naive, look into the autoconf docs and/or mailing lists to see why. You actually have to compile for header checks and link for library checks, everything else is plainly wrong, because you'll probably miss dependencies, pick up the wrong stuff, etc.
Right, that's exactly what it does. We checked used the autoconf macros as guidance.
One suggestion I've seen is just to improve the ffi pre-processors. The c2hs tool is in a position to discover if the calling convention is stdcall or ccall so it could generate the foreign imports correctly. [...]
This wouldn't help much: The foreign imports in OpenGL are written by hand, and when the OpenGL ARB ever manages to release some consistent, machine- usable and complete API description (the current .spec files fail in almost all these aspects), they will be generated from that, not from C headers, because, not surprisingly, the latter lack a lot of information.
I don't see that the two approaches are exclusive. For example with Gtk+ we also generate from an incomplete API description with manual adjustments because of lack of info. However we generate .chs files that then get processed by c2hs so that we can check if our binding at least matches the C header files. Certainly the C headers are not enough (no info about memory management) but the bindings do at least have to be consistent with the C headers on the current platform. And the C headers do say if the calling convention is ccall or stdcall (otherwise the C progs would not work). But this is not a short term fix, it'd be a complete change for the binding so I'm not seriously suggesting it.
Anyway, so that's why I'd like us to look in detail at what features we need in Cabal to let us switch most packages from using ./configure scripts to using Setup.hs scripts.
As I said in another email: I'll happily review and accept patches for this, but I won't spend any effort on re-inventing the autoconf wheel in Haskell.
I'm not asking you personally to do that. I'm asking for help from you or others on identifying the tests that we need to do to support our most common Haskell bindings packages. Duncan
The thing is, it doesn't really matter if autoconf macros work fine for every Unix ever invented. The Windows users simply cannot use packages with configure scripts. They complain about it a lot. We can call them foolish for not installing cygwin/mingw, but they will not do it and instead will simply not use our software and/or continue to complain.
"Windows users" - that's a lot of different people to generalize over.
From what I've heard, most complaints are about assumptions made by non-windows users that turn out not to hold on windows, causing things to fail on windows. Which seems reason enough for failure reports, otherwise known as "complaints".
If someone wants to use a unix shell on an unknown platform, they should at least check that one exists there or -even better- provide one, not just assume that there'll always be one (and then be surprised about getting complaints from "those windows users"). Same for autoconf, make & co. If someone mixes up GCC's standard layout, they need to adjust "everything" for those changes, and when that turns out to be rather difficult, it is no surprise if GCC seems unable to pick the right include or library paths. This particular issue has just recently been fixed in GHC head, I understand (will that fix cause problems for cabal, btw, when the existing path hacks are no longer needed?). http://hackage.haskell.org/trac/ghc/ticket/1502#comment:12 Apart from causing lots of other path issues (and confusing tools like cabal, which tried to compensate by special-case code), this complicated the process of installing headers and libraries used by FFI bindings, at least for those windows users who didn't build their own GHCs, with the help of a full GCC install. And so on.. Listen to the complaints, there is (usually) a real issue behind them. A couple more examples of why installing the tools that some cabal packages rely on isn't straightforward: I like and use cygwin, but when installing it, one has to be careful to include all the bits that are needed, preferably leaving out the bits that might cause confusion when used for GHC/Cabal (such as a second GCC installation). I once tried to capture the list of dependencies needed for building GHC in a cygwin pseudo-package (no contents, only dependencies), which made that easy. http://www.haskell.org/pipermail/cvs-ghc/2005-May/025089.html http://hackage.haskell.org/trac/ghc/wiki/Building/Windows/Cygwin But then cygwin's installer added security signatures, and I don't think such were ever added to the pseudo-package, the dependencies are also not uptodate anymore (I don't have write access to where it was put). Nowadays, one could put the cygwin pseudo-package into a cabal package on hackage, including the necessary signature, and that cabal package could run the cygwin installer with the dependencies given in the cygwin package (assuming there's a commandline interface to the cygwin installer) or at least users could run the cygwin installers with an updated version of that cygwin package, and get a cygwin setup useable for cabal packages. Others like msys, but for some reason the msys developers hardly ever put up a simple installer, one usually has to collect various bits and pieces in the right version, then unpack them on top of each other - very far from automated one-click installation. Simon recently collected the pieces needed for building GHC, so one could now point windows users to http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows for "one-stop shopping". One could probably do better by collecting those pieces into a cabal package (assuming the license is favourable), but I could never find documentation for using the mingw/msys installers from the commandline, as a cabal package would need to do. Someone familiar with those installers might not find this difficult. Improving Cabal to replace autoconf is a nice long-term goal, but in the meantime, things could be made a lot easier for those "windows users". GHC using the standard layout for its GCC is one step, packaging up the msys and cygwin dependencies would make it straightforward to install those correctly (someone with installer knowledge might even be able to automate that from the cabal commandline..). Then windows users could easily install either msys or cygwin, and the remaining issue would be how to install the headers and libraries for cabal packages with ffi bindings. Just as on other platforms. Claus PS. Don't think of "them" and "they" vs "we" and "us" and "our software". It doesn't help. Neither does classifying bug reports as "complaints". -- It is not that we think of "other" as bad, -- it is that we think of bad as "other".
On Thu, 2009-04-30 at 23:31 +0100, Claus Reinke wrote:
The thing is, it doesn't really matter if autoconf macros work fine for every Unix ever invented. The Windows users simply cannot use packages with configure scripts. They complain about it a lot. We can call them foolish for not installing cygwin/mingw, but they will not do it and instead will simply not use our software and/or continue to complain.
"Windows users" - that's a lot of different people to generalize over.
Yes, I was generalising. There are those users who are prepared, even happy to install cygwin, and there's everyone else.
From what I've heard, most complaints are about assumptions made by non-windows users that turn out not to hold on windows, causing things to fail on windows. Which seems reason enough for failure reports, otherwise known as "complaints".
If someone wants to use a unix shell on an unknown platform, they should at least check that one exists there or -even better- provide one, not just assume that there'll always be one (and then be surprised about getting complaints from "those windows users"). Same for autoconf, make & co.
You mean that we should be shipping a haskell platform with a full copy of mingw + all the tools to make configure scripts run? I doubt that'll make people happy. They'll complain about it not being "native".
If someone mixes up GCC's standard layout, they need to adjust "everything" for those changes, and when that turns out to be rather difficult, it is no surprise if GCC seems unable to pick the right include or library paths. This particular issue has just recently been fixed in GHC head, I understand (will that fix cause problems for cabal, btw, when the existing path hacks are no longer needed?). http://hackage.haskell.org/trac/ghc/ticket/1502#comment:12
Apart from causing lots of other path issues (and confusing tools like cabal, which tried to compensate by special-case code), this complicated the process of installing headers and libraries used by FFI bindings, at least for those windows users who didn't build their own GHCs, with the help of a full GCC install.
And so on..
In principle there is no problem with finding the mingw headers on Windows. All we need is that the rts or base package specify them in the include-dirs in the package registration info. Cabal uses the same info.
Listen to the complaints, there is (usually) a real issue behind them.
I don't think the problem is that we've had a messed up mingw.
A couple more examples of why installing the tools that some cabal packages rely on isn't straightforward:
But there is a significant number of Windows users who do not care to install these tools at all. Making the stuff work better for people who choose to use cygwin is great. I have no objections to that. But the majority want "stuff" to work without them having to install cygwin. In this case "stuff" often means random hackage packages and many of them are using configure scripts.
Improving Cabal to replace autoconf is a nice long-term goal, but in the meantime, things could be made a lot easier for those "windows users". GHC using the standard layout for its GCC is one step, packaging up the msys and cygwin dependencies would make it straightforward to install those correctly (someone with installer knowledge might even be able to automate that from the cabal commandline..).
Then windows users could easily install either msys or cygwin, and the remaining issue would be how to install the headers and libraries for cabal packages with ffi bindings. Just as on other platforms.
Making them easier to install would probably convince many Windows users to install one of them.
PS. Don't think of "them" and "they" vs "we" and "us" and "our software". It doesn't help. Neither does classifying bug reports as "complaints".
I'm not complaining about people complaining. :-) I'd like to see things work better on windows. Duncan
If someone wants to use a unix shell on an unknown platform, they should at least check that one exists there or -even better- provide one, not just assume that there'll always be one (and then be surprised about getting complaints from "those windows users"). Same for autoconf, make & co.
You mean that we should be shipping a haskell platform with a full copy of mingw + all the tools to make configure scripts run? I doubt that'll make people happy. They'll complain about it not being "native".
The platform includes GHC, which already includes mingw (GCC)!-) What I meant was a cabal package bundling the pieces of msys (sh, autoconf, make,..). And, no, the haskell platform doesn't need this, so it should be a separate package. But cabal install should know that this package would be nice to have at hand if building a package that uses build-type:configure on windows.
just fixed: http://hackage.haskell.org/trac/ghc/ticket/1502#comment:12 In principle there is no problem with finding the mingw headers on Windows. All we need is that the rts or base package specify them in the include-dirs in the package registration info. Cabal uses the same info.
In practice, we have instructions like these circulating (these being examples of the better kind, as they actually got things working): http://joelhough.com/blog/2008/04/14/haskell-and-freeglut-at-last/ http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ And I've lost count of the number of times the finding of mingw headers or libs has caused bugs (which usually went unnoticed on the author's machine because the author would have a full copy of mingw in c:/mingw, where gcc looks for things when everything else fails - oh, unless you're using ghc's gcc on d:, when this failsafe would suddenly fail as well, until recently). Perhaps cabal had no problems with this, but problems were plenty and initially non-obvious. So I'm happy that this fix has eliminated one common cause of problems with installing Haskell software on windows. Every little bit helps.
A couple more examples of why installing the tools that some cabal packages rely on isn't straightforward:
But there is a significant number of Windows users who do not care to install these tools at all.
Making the stuff work better for people who choose to use cygwin is great. I have no objections to that. But the majority want "stuff" to work without them having to install cygwin. In this case "stuff" often means random hackage packages and many of them are using configure scripts.
If cabal can do autoconf/configure stuff without having autoconf/ configure installed, great. Someone could write SH as a Haskell DSEL, for starters, then replicate the autoconf stuff (its all just SH libraries and some macro processing, right?). But I'm not optimistic about that in general. There probably are windows users who don't want to have msys or cygwin on their machine, but I suspect there are more windows users who simply don't want to bother with msys (so if cabal installed and used it internally, they might accept that, just as they accept, or at least live with, GHC installing and using mingw internally).
Then windows users could easily install either msys or cygwin, and the remaining issue would be how to install the headers and libraries for cabal packages with ffi bindings. Just as on other platforms.
Making them easier to install would probably convince many Windows users to install one of them.
It would also simplify cabal package installation instructions, and avoid the "it doesn't work and it thinks it is on unix so I don't see how it could possibly work" feeling. Instead, cabal install would simply point out another package dependency that needs installing.
I'm not complaining about people complaining. :-) I'd like to see things work better on windows.
I'm not surprised!-) Claus
participants (7)
-
Alexandr N. Zamaraev -
Claus Reinke -
Duncan Coutts -
Jeff Zaroyko -
Manlio Perillo -
Peter Verswyvelen -
Sven Panne