A new ebuild for the HsShellScript libraries. Reproducible: Always Steps to Reproduce: 1. 2. 3. It has been also created a patch, included with this bug report. It modifies the Makefile to avoid problems registering the ghc packages.
Created attachment 49250 [details] New ebuild - HsShellScript This is an ebuild for building the Haskell Unix libraries. It seems working fine here.
Created attachment 49251 [details, diff] Patch for HsShellScript A patch for the hsshellscript ebuild. It modifies the Makefile.
That's great, thank's for the contribution. Some comments: the lib should be installed under: /usr/lib/ghc-$VERSION/ either directly or in a subdirectory You can use the function $(ghc-libdir) from the ghc-package eclass to find the right directory. That way we can install versioned packages that will not break when you change the version of ghc. You stripped the gh-pkg line out of the Makefile. That's fine. It'd be nice to provide a ghci .o file (that's what the --auto-ghci-libs parameter to ghc-pkg does) . Since we have to do the package registering in the build rather than the makefile we alos have to make ghc ghci .o file in the ebuil too. The function to use is ghc-makeghcilib (also from the ghc-package eclass). Another thing I noticed is that the package .conf file for hsshellscript still has variables in it like DEST_LIB, DEST_IMPORTS. The normal makefile passes these as environment variables and ghc-pkg expands them. In the ebuild we currently do not have a way to pass environment variables to the bit where it actually registers the package. You will probably have you use sed or something to insert the appropriate values. eg: in the gtk2hs ebuild I have to replace ${pkglibdir} with $(ghc-libdir)/gtk2hs so I say: sed -i "s:\${pkglibdir}:$(ghc-libdir)/gtk2hs:" \ ${D}/$(ghc-libdir)/gtk2hs/*.pkg before calling ghc-setup-pkg You would probably want sed -i "s:\${DEST_LIB}:$(ghc-libdir):" \ ${S}/lib/hsshellscript.pkg sed -i "s:\${DEST_IMPORTS}:$(ghc-libdir)/imports:" \ ${S}/lib/hsshellscript.pkg That is if you are installing directly in the ghc lib dir otherwise add the appropriate subdirectory. I'm not sure we have a policy as to whether we should always installin in the ghc lib root or in a subdirectory. The other thing is that the docs should go in a versioned subdirectory. This seems to be gentoo policy/convention. So that'd be: /usr/share/doc/hsshellscript-2.1.0/ You can delete the pkg_postinst() and pkg_prerm() actions. Inheriting from the ghc-package eclass means this happens automatically. It will register whatever you installed with ghc-install-pkg. I'm not sure that we need to explicitly mention sys-devel/make as a DEPEND. I think that is implicit.
I haven't looked at the ebuild in detail yet. One way to get the variable expansion and ghci library built for free is to do a sed -i "s:ghc-pkg:$(ghc-getghcpkg) -f ${S}/$(ghc-localpkgconf):" Makefile Then you'd call ghc-setup-pkg without any arguments, and let the Makefile install the package into a local package config file first, which will then be installed correctly by the eclass. Thanks very much for the submission. ks
Created attachment 49300 [details] hsshellscript-2.1.0.ebuild Here's an ebuild taking into account some of my suggestions. I've not tried kosmikus's suggestion, 'coz I did it before he suggested it. I have to say I don't entirely understand the doHtml command. The ebuild docs are not very expansive on the subject. What does the "-A haddock" mean?
Ok, seems like it works fine with that latest ebuild sent by Duncan. Apparently there is no need to the 'if use doc...' section. Looks like it works fine without it. Also, i couldnt get it working with the Andreas suggestion, could anyone?
The ebuild is now in CVS, with KEYWORDS="~x86". I have chosen for an sed-call instead of the patch, but different from what I hoped in comment #4, the ghc-makeghcilib call is still required. I've removed ~sparc, because it depends on >=ghc-6.2, and there are no suitable ghc ebuilds in portage currently. I guess this is something that Duncan pursue further. I'm tempted to remove the "doc" USE flag, because currently, it doesn't have any effect. The tarball contains prebuilt documentation; no haddock dependency required. ks
> I've removed ~sparc, because it depends on >=ghc-6.2, and there > are no suitable ghc ebuilds in portage currently. I guess this > is something that Duncan pursue further. Oh yes of course, I'd forgotten there was no sparc ghc ebuild. It works fine for me here (except ghci). I was working on an ebuild that would install ordinary prebuilt .tbz ghc packages. I'll finnish that off.
This one can be closed, I guess.
