OK, I think I'm starting to remember more bits and pieces...
On Sun, Aug 09, 2009 at 18:18:09 +0200, Lennart Kolmodin wrote:
> I recently tried to make Gentoo Linux ebuilds for wxHaskell. We've had
> support in the past, for the 0.9.x series, and would like to support the
> new 0.11.x too. I spent a few hours just to make it install, and I'm
> still not satisfied with the result :)
So let's see if we can make this easier at last!
> The ebuild itself is located at:
> http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/wxcore/wxcore-0.11.1.2.ebuild
> and documents itself.
> You can find the patches at:
> http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/wxcore/files/
> and they have also been documented.
One thing to watch out for is the work-in-progress in the Darcs wxHaskell.
We've started by moving away from the Make build method in wxcore and just
using Simple instead (for now, maybe Custom later). This means that
installation would proceed in three phases, one focused on wxc, and then two
simple Haskell ones for wxcore and wxc respectively. If we pull this off, we
may have a more straightforward route to making ebuilds for wxHaskell.
The big gotcha here is that the work was never finished so I think if you try
and cabal install wxcore from the Darcs wxHaskell you won't be able to build
any apps with it because of a linker error (it's not finding wxc).
Re-reading
http://sourceforge.net/mailarchive/forum.php?thread_name=op.ur3r8oe4g8rhh0%40shelarcywin&forum_name=wxhaskell-devel
it sounds like "all" we need to do is to throw in an extra-libraries
and extra-lib-dirs pointing to wxc and where wxc lives respectively.
But here's the question: how do we know what wxc is called? and how
do we know where it lives? Reading
http://sourceforge.net/mailarchive/message.php?msg_name=op.ur50y0kmg8rhh0%40shelarcywin
I see that use of pkg-config was my proposed solution, but Shelarcy
pointed out that Windows users may not have pkg-config. I wonder
how other packages deal with in practice?
> Making an ebuild for the wx package takes less than 2 minutes, prefect :)
> Many distros can automatically generate description files for their
> package systems from correctly packaged cabal applications/libraries.
> Naturally we want to make it easy for the poor distro maintainers, right? ;)
Yeah! So in my ideal world, we would go a really radical route, and stop trying
to make the configure script and makefile smarter. Instead, I think we should
remove anything Haskell-related and outsource that to Cabal.
> It's sure some work that has gone into making it use cabal though, even
> if it isn't perfect.
That's exactly right. Shelarcy and the wxHaskell crew have put in a lot
of effort into extending the configure script and the makefile to fit in
with Cabal and the cabal build system. To be clear, although I gripe
rather frequently about this [without producing much in the way of
actual code], I am very grateful for the work that has already gone
into making it even possible to install this with "sudo cabal install
wxcore" in the first place.
For the longest time, we've been just two centimeters away from
delivering that finishing blow, to making it all "just work".
> What do we need to make it easier, to use more of cabal? Any features in
> those ./configure and makefiles cabal doesn't have?
OK, this isn't quite what you're asking for, but for some things apparently
needed in Cabal/cabal-install, here are some of Shelarcy's comments:
from
http://www.haskell.org/haskellwiki/WxHaskell/Building
| Cabal doesn't works well currently. This is Cabal and cabal (install)'s
| problem (e.g. 394, 431). And current cabal 0.6.0's dependency solver has
| problem.
|
| So, you should build and install wxHaskell by hand (at least wxcore package).
|
| If you want to build and install wxHaskell by cabal command, you must use following command.
|
| > cabal install wx --configure-opt="--user --enable-split-objs --hcprof"
|
| or
|
| > sudo cabal install wxcore --global
| > cabal install wx
http://hackage.haskell.org/trac/hackage/ticket/394 (fixed in Cabal 1.8)
http://hackage.haskell.org/trac/hackage/ticket/431
> I haven't really digged into wxhaskell's build system in many years, but
> I remember it builds and uses an application (wxdirect?) to generate the
> bindings to the underlying C library. Maybe we could use a field
> "installable" similar to existing "buildable" to be able to build in in
> the wxcore.cabal file?
This reminds me. I bet that at this stage, we would not be able to upload
wxcore onto hackage because with our incomplete wxc/wxcore split, we would
only be able to cabal install wxcore after having done 'make' to compile
and run wxdirect :-(
So the challenge is may be to extend the Setup file for wxcore with some sort
of build pre-hook to run wxdirect on the C header files and Eiffel constants.
I really hope there's no dependency on wxc for any of this and that we can
just ship these header files.
Another problem is getting wxdirect in the first place. We now have a simple
wxdirect cabal package which we could dump on Hackage (it's only purpose in
life will be to help build wxHaskell and that's OK). I don't know how to
express a build dependency on wxdirect because it's an executable, but maybe
one workaround would be for wxdirect to expose a sort of null "library"?
> What else?
Here is a what I think we still need to do:
1. Tell the wxcore package where the wxc library lives using
an extra-libraries and extra-lib-dirs field
This may require extending the makefile so that we give
wxc some sort of standard name. Or maybe this could
involve using pkg-config and finding some sort of workaround
for Windows users.
2. Add some sort of pre-hook so that wxcore runs wxdirect
in such a way that we can compile the source that's
generated as part of wxcore. I'll bet this shouldn't be
too horrible; people use Happy and Alex after all, right?
3. Depend on wxdirect and release it on Hackage.
4. Figure out how to still have good binary installers for
wxHaskell. Maybe only have installers for wxc itself?
Thoughts?
--
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
|