thanks, most items seem to have been addressed already. there is a slight
hickup in time/Setup.hs (wrong type for system "make" in runTestScript),
and ALUT is still not stepping aside silently, unlike OpenAL, for instance.
A patch to simplify the Windows story would be great, but it's fairly
low priority for me as (a) it does actually work at the moment
(b) removing one or two configure flags doesn't really make much
difference; copy and pasting 3 or 4 is just as easy as 1 or 2, so you
really do have to solve all the issues to get a payoff.
there seem to be three groups of windows ghc builders: (a) mingw/msys,
(b) mingw/cygwin, with all of gcc/ld taken from mingw, (c) mingw/cygwin,
with two sets of gcc/ld. [i happen to be in (b)]
(a) and (b) are easier - if any gcc/ld is found, its the one we want. for (c),
we need to be sure that the mingw versions are selected, unless someone
explicitly asks for a cygwin build.
if i understand the configure code, (a/b) users can already omit the --with-ld
path, and configure will figure out the right thing. omitting the --with-gcc path
as well will lead to WhatGccIsCalled being set to "gcc" only, no path. the latter
will lead mk/config.mk to set GccDir incorrectly, which is needed in Makefile
install:: target.
if configure could set WhatGccIsCalled to the full gcc path, (a/b) users might
be able to omit both -with-gcc/ld. something like 'cygpath -w `type -p gcc`',
only that 'type -p' is a bashism?
for (c) users, configure would need to check that the gcc/ld it finds on the
path
are the mingw ones. for gcc
$ gcc --version | grep mingw-special ; echo $?
gcc.exe (GCC) 3.4.2 (mingw-special)
0
seems to be promising, but i don't know what the cygwin gcc returns there (i
think it was 'cygwin special', but please check)?
for ld, i don't see any direct indicator. one could try looking at the default
linker
script (hoping that the cygwin ld only pretends to be mingw when asked):
$ ld --verbose | grep SEARCH_DIR | grep mingw ; echo $?
SEARCH_DIR("/mingw/mingw32/lib"); SEARCH_DIR("/mingw/lib");
SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
0
if configure can't find gcc/ld, it needs to complain, if it finds non-mingw
gcc/ld
for a mingw build, it should at least give a warning, to avoid later
complications.
that would leave only the ' --host=i386-unknown-mingw32' (which always gives
a warning, btw). for (a) users, that should not be needed, for (b/c) users, it
makes
sense, although the default for windows could be switched to mingw?
4. make falls over in ALUT (i don't have OpenAL installed, so neither that
nor ALUT should be built). last part of log appended below.
..
I see 3 possible solutions:
1) If Cabal find the dependencies aren't satisfied then it puts
"buildable: False" somewhere and exits successfully. I quite like
this from a consistency point of view (it's what happens when
./configure decides that the package is unbuildable).
this is also what Cabal setup already does, eg, for the OpenAL binding, when
no OpenAL installation is found, so i don't understand why the setup behaviour
differs when ALUT cannot find an OpenAL binding?
2) We remove ALUT, GLUT, HGL, OpenAL (and OpenGL too for consistency?)
from extralibs. I think these are probably among the least use extralibs
anyway.
please, no!-) HGL is a source of trouble, and while i don't have an opinion on
it,
its popularity seems limited only by its frequently not working. OpenGL has been
the most stable, portable, and maintained graphics option i know, and GLUT is
the
simplest user interface for it. these two are not only useful and a real
salespoint, they
are also good testcases for language features such as FFI. so, extralibs is
exactly
where they belong. i haven't yet used OpenAL/ALUT, but i expect to, so i'd like
them to have the same status and stability/testing as i've come to expect for
OpenGL/GLUT.
thanks,
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
