How to install HOpenGL to Windows?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

How to install HOpenGL to Windows?

Alexandr N. Zamaraev
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Jeff Zaroyko
On Wed, Apr 8, 2009 at 3:14 PM, Alexandr N. Zamaraev
<[hidden email]> wrote:
>
> 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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Peter Verswyvelen-2
In reply to this post by Alexandr N. Zamaraev
1) install "cabal-install". download this file 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 (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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Manlio Perillo-3
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Peter Verswyvelen-2
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 <[hidden email]> wrote:
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


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Sven Panne
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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Duncan Coutts
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Sven Panne
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.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Duncan Coutts
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Sven Panne
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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Duncan Coutts
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Claus Reinke
> 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".


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Duncan Coutts
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to install HOpenGL to Windows?

Claus Reinke
>> 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


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe