Bugzilla Bug 50998

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 an attachment (id=31385) [edit]
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 an attachment (id=31529) [edit]
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.