Here's an ebuild for the latest released version of gtk2hs It was based on the wxhaskell ebuild it doesn't build documentation at the moment (no doc USE flag) as I can't get it to build at all. I'll have to talk to the main gtk2hs developer.
Created attachment 31385 [details] gtk2hs-0.9.5.ebuild
looks very good ... I will test it, but probably not commit it until Monday because I am away during the weekend. We should probably factor out the package registering and unregistering code in a haskell.eclass or ghc-package.eclass or whatever, as soon as we have a few more packages around ... ks
Installs fine, only in the end, I get: * Registering gtk2hs packages warning: can't find GHCi lib `gtk2hs.o' Reading package info from "/usr/lib/ghc-6.2.1/gtk2.conf"done. Expanding embedded variables... done. Saving old package config file... done. Writing new package config file... done. warning: can't find GHCi lib `mogul.o' Reading package info from "/usr/lib/ghc-6.2.1/mogul.conf"done. Expanding embedded variables... done. Saving old package config file... done. Writing new package config file... done. Doesn't gtk2hs build ghci packages? If not, then why? Could this easily be fixed by us? Furthermore, could you give me instructions of how I can compile a minimal test file with the installation, to see whether the installation works? Thanks, ks
The standard make targets don't seem to build ghci .o files not sure why. For now, I've modified the ebuild to do it. The sourceview package does not work in ghci at the moment so I do not make a .o that one. As for tests, in the source tarball under the demo directory there are a bunch of demos. In fact I think they get built just not installed when you make; make install. I should see about not building the demos to save time. To make sure they really work move the demos from the build tree and change the Makefiles appropriately, as otherwsie they'll use the localpackage.conf rather than the installed ghc packge .conf files. I'm attaching a slightly updated version with the ghci .o fix and some changes to the deps & use flags. There is no glext stuff to build atm so I've deleted that dep. Also building docs is broken and we're moving to using haddock soon so we're not goin to fix that now. Also, I've grouped glade under the general gnome USE flag. It is possible to build the glade extension without the other gnome extensions but I'm not sure it's terribly important. At the moment with a local glade USE flag, people are likely to not notice and not get glade built when they actually wanted it (since local flags default to off). Do you think people actualy want finer grained dependencies?
Created attachment 31529 [details] gtk2hs-0.9.5.ebuild update to build ghci .o files and simplify deps
gtk2hs is in cvs now. Thanks for the good work. With glade, we can keep in mind that we could introduce a local use flag again, and modify the ebuild in case someone requests more finegrained control. Maybe even a global use flag for glade will be introduced some day ... Please test the final ebuild as soon as available on your machine. Best, Andres
It builds for me with USE="gnome" and with USE="-gnome". It worked for another gentoo user too (install & uninstall). He was using ghc-bin. My only worry was that in the case that someone is using ghc-bin the files still get installed to /usr/lib/ghc-6.x.x/. However I guess this is ok since the package file will point to the right place and ghc should pickup the files ok. So I guess that's fine. We still spit out a ton of warings when compiling general/Gtk.hs, but that's a problem for me with my developer's hat on rather than with my packager's hat. I may update the ebuild to make c2hs build & run faster (and not build the demos). Or I may save it for the next release.
/usr/lib isn't perfect when using ghc-bin, but I guess it's okay for now. We can also fix it, though, either by checking the existence of /usr/lib/<ghc-version> and /opt/... in the ebuild, or by using the --print-libdir option of the ghc binary. Generally though, don't spend too much time on making the ebuild better (w.r.t. influencing the build process), because everything that's in there needs to be maintained and increases the risk that adaptions become necessary for future releases. If you are an upstream author or have good contacts, better add improvements that facilitate packaging there ... ks
I've had 2 more sucessfull build reports. Something someone reported was that when unmerging ghc (after emerging & then unmerging gtk2hs), the /usr/lib/ghc-6.2/ directory was not removed because the modification time on /usr/lib/ghc-6.2/package.conf had changed. This makes sense of course since ghc-pkg does modify this file whenever a package is added or removed. I wonder if it would be sensible (or possible) to persuade ghc to keep its package.conf file somewhere under /etc ?
Great. I doubt that installing package.conf under /etc would do any good. That would not remove the problem, but rather make it worse, because you have to manually update the file due to config protection, although it's rarely manually edited. One way to deal with it would be to remove it during postrm of ghc, but I am not convinced that this is the right way to go either. I am inclined to say that one file left is okay.
