The latest release of the nhc Haskell compiler, nhc98 1.16, can be built and installed just by executing: ./configure +docs make make install It worked out of the box an my machine. (I should mention that I do have ghc 5.04.3 installed and used that to bootstrap the compiler. Supposedly, nhc98 should build with just gcc as well, but I didn't try that.) It would be nice to have an ebuild for that package. This report is related to bug report #10155. Reproducible: Always Steps to Reproduce: 1. ./configure +docs 2. make 3. make install
Created attachment 10343 [details] ebuild I have updated the existing ebuild. Works for me on x86. Modifications w.r.t. 1.12: I changed the hmakerc hack. The update of hmakerc is disabled in the configure script of the package when using DISTFILE. One possibility would be to patch the configure script, but I decided to copy the corresponding lines from there and do the update manually. The advantage over the 1.12 hack is that all contents of hmakerc remain intact. The final result will be the same as with a manual installation. Furthermore, I simplified the installation of the documentation somewhat. The ebuild assumes the type synonym patch which is available from ftp://ftp.cs.york.ac.uk/pub/haskell/nhc98/patch-1.16-typesyn in the /files directory. It would probably be better to let it be downloaded by the ebuild as well. Andres
Hi Andres. Thanks for an ebuild! I have modified it to fetch the patch instead of just looking for it in ${FILESDIR}. The ebuild is committed, please test. George
The config file "/usr/lib/hmake/ix86-Linux/hmakerc" contains all wrong paths for nhc98.
Hi Peter. Thanks for catching this! I have added a sed instruction to correct the generated hmekerc file. The alternative might be to jst install some pregenerated hmakerc (but this will not catch ghc if installed or will have the converse problem). Please test. George
Created attachment 10490 [details] variant ebuild to fix path problem Problem described by Peter was not detected by me because the build worked if you already had nhc98 installed. George's fix does the job, but then the lines between einfo "Adjusting ... hmakerc" and #need to adjust paths in hmakerc are superfluous and should be removed. Alternatively, one can do the stuff after merging. I do not know whether that is a good thing, but it seems to work. This is what the attached build does. Best, Andres
Reopening bug as requested by george on irc :)
Yup, that worked well (I wonder what I did differently, when I was trying the same approach before resorting to sed :)). BTW, there is no need to issue a -r1 in this case - this is an "ebuild clean up" rather than fix to some problem. No need to force rebuild on everybody who has it already installed, as the end result did not change... As for what is better: by doing sed in src_install we register this new version of hmakerc in the database, so it gets deleted if unmodified by user. While by doing configuration from pkg_postinst we pretty much guarantee that this config file will be left around, just like with the user-modified hmakerc. We can of cource delete it in pkg_postrm, but that's undesirable (well, plain wrong), as user might have modified it. But then I feel better about doing configuration during pkg_postinst, as it might pick up installed stuff in a more correct manner. Thus, effectively, pkg_postinst created hmakerc should be treated as almost "user-generated", alleviating the dilemma :). Ok, now some organizational stuff: Andres: I suppose you have studied http://www.gentoo.org/doc/en/gentoo-howto.xml and http://www.gentoo.org/doc/en/eclass-howto.xml ;) now you can add this to the pool: http://www.gentoo.org/doc/en/policy.xml and eventually the "Release policy" as well, but the former one is more to the point right now. Then just find me on irc and we can go about committing this to cvs tree, unless you want to go through some other stuff first.. Afterthat I'll create a dev-haskell category (this has been already approved) and I'll leave you in charge of filling it (but please CC me on few first ebuilds you will be processing). Actually I have a few bugs of relevance on me right now, mind if I reassign them to the right owner ;)? George
Hi George. I have read most of the material you pointed out. No, I don't mind if you reassign some of the bugs to me. Andres
Ok then, here you go :). Sorry, I missed you on irc today. Lets try tomorrow then.. George
The ebuild has been added now. The most recent version (which is marked testing, currently) does no longer include the "hmake" utility, which now has an own ebuild as dev-haskell/hmake. This should also prevent the problem with the wrong paths in hmakerc. Closing the bug, but, of course, you're all welcome to test!
Are you sure it is a good idea to install nhc98 but not hmake? I like the idea of having hmake a separate package, so you can install it without installing nhc98, but my guess is that many packages using nhc98 will rely on hmake being packaged up with it. Hence, I'd say: When you install nhc98, you'll get hmake all the same. Furthermore, this is consistent with the other stuff included in nhc98! Otherwise, we'd have to split Hood, GreenCard, etc. off of nhc98 as well! Oh, by the way: Has anyone actually _used_ hood as it comes with nhc98? I see it's there, but requires Java to work ... So I cannot really test it. No Java on my machine as long as I can help it. ;-)
The motivation I had for separating out hmake was the following: I know and remember that hmake sometimes is released as a separate tool in an improved version, apart from nhc98. Apart from that, it certainly is useful even without having nhc98, although it has become less so since GHC comes with the --make option ... Still, if people want to upgrade to such a more recent version of hmake, then it also means that nhc98 should not have hmake included, because otherwise a reinstall of nhc98 might accidentially overwrite it. I don't really see the dependency problem you mentioned, because all packages that depend on hmake can be made dependent on hmake in portage. One thing is worth consideration, however. We can keep the separation of nhc98 and hmake and still force installation of hmake on installation of nhc98 by making nhc98 PDEPEND on hmake. That means, nhc98 will depend on hmake, but install it actually only _after_ it has installed nhc98. I am not sure what's the best solution here. As long as I do not see a reason that really keeps the current configuration from working, I would be inclined to leave things as they are, for now. About the other tools that come with nhc98, it should be checked whether they are shipped as separate packages as well, and whether the specific versions of these tools shipped with nhc98 are usable and useful in conjunction with GHC or Hugs as well. If they are, it might be good to separate them out in a similar way to hmake. If they are not, they can be seen as parts of nhc98 IMHO. As to hood: no, I never used it. I did use hat, though, and I plan to include an ebuild for that soon ... Best, Andres
can that be closed andres?
Yes, you can close it. This bug (and all the others that you have modified) had already been closed and have only been opened again due to information loss in the bugzilla database. Andres
fine -> close ^^
