Hi Evan, thanks for your contribution. In fact, I'm working (struggeling) right now to get the different pieces of Gtk2Hs built with cabal. Cairo as a leaf package will be one of them. I'm don't know if you ran into many problems using the standard c2hs pre-processor when compiling the c2hs files of Cairo. Gtk2Hs has used a custom c2hs and I'm bundeling that up as a separate tool, too. If you managed to build Cairo without this customized version, then that's fine. However, I'm not sure if any of the other modules of Gtk2Hs requires the .chi files that c2hs generates. If so, you need to create a custom Setup.hs that installs these files in the same location as the .hi files. I'm currently working on this so you might just be able to take my Setup.hs file and use it in the Cairo pacakge.
I'll look at your patch. If it all makes sense, I'll try to apply or the merge in some other way. I'll keep you (and the list) posted, Axel. On 08.02.2010, at 03:15, Evan Martin wrote: > Hi, > > I recently wanted to poke around at Cairo and noticed it was only > available as part of gtk2hs. > It seemed to me Cairo ought to be a separate library so I made an > attempt at splitting Cairo out of the gtk2hs build. While I was at > it, I converted the build to just Cabal, which means it'd also be > available via cabal-get. This involved converting the Cairo-specific > code to use the upstream c2hs among other changes. > > My questions for you: > - Does this plan in general seem desirable to you? In theory, Cairo > can be built against other targets (like in this open issue: > http://hackage.haskell.org/trac/gtk2hs/ticket/1180) and I guess having > an independent build could make adding those easier. > - Where can/should I host the independent Cairo package? > - Do you really care about supporting GTK versions older than 2.8 > anymore? I found while looking through the gtk2hs build that a lot of > the complexity is supporting what seems to me to be obsolete > configurations. > - How can I test that this change actually works? > > I've attached my patch (minus the patch that just rm -r's the "cairo" > subdir of the gtk2hs distribution) that *seems* to work, but I > probably overlooked some pieces. > If this general idea looks good to you, I'd like advice on how to > better get this ready in a state to commit. (E.g. one huge patch? > Multiple patches? I'm not too good with darcs...) > > Hopefully this could be the first step in a larger process, which > would be to split all of the independent libraries out of gtk2hs. For > example, I could see pulling "svgcairo" library out into its own > package as well, probably renaming it to an rsvg binding (since that's > really what it is) in the process. > <use-cabalized-version-of- > cairo > .dpatch > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term > contracts > Personal 24x7 support from experience hosting pros just a phone call > away. > http://p.sf.net/sfu/theplanet-com_______________________________________________ > Gtk2hs-devel mailing list > Gtk2hs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
