Re: [Gtk2hs-devel] cabalizing cairo

[Axel S. <Axe...@in...>]

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
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel