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
pgpy8BwoDdUWs.pgp
Description: PGP signature
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
