I noticed two problems when trying to build the Haskell compiler ghc via the portage system: - The configure script does not find my SGML/DocBook catalogues, even though I do have them installed. - The build fails. When trying to build, I get the following errors: [much, much more omitted] CTypes.hc:55324: warning: excess elements in array initializer CTypes.hc:55324: warning: (near initialization for `CTypes_zdfReadCChar_closure.payload') Prologue junk?: czvw_ret: movl $0, 16(%esp) movl $0, 20(%esp) movl $0, 8(%esp) movl $0, 12(%esp) make[2]: *** [CTypes.o] Error 255 make[1]: *** [all] Error 1 make: *** [all] Error 1 !!! ERROR: The ebuild did not complete successfully. !!! Function build_stage1, Line 5, Exitcode 1 !!! (no error message) The configure script comlains about my perl version (5.6.1-r7), but that's about the only reason I can see. Any clues anybody?
Ditto. Exact same error for me.
Created attachment 5570 [details] typescript file of CFLAGS="" CXXFLAGS="" build I also get the same error when trying to bootstrap ghc. The attached file was my attempt. Is this a gcc bug? View the typescript with more.
Created attachment 6052 [details] ghc-5.04.1.ebuild Ehh, this works for now. (binary ebuild)
I just tried to build the GHC package using the (manually installed) binary version of GHC 5.04.2 and got _very_ far. Unfortunately, the build fails in stage 2 with the following error: ../../ghc/compiler/ghc-inplace -ldl -fglasgow-exts -cpp -Iinclude -funbox-strict-fields -package-name base -O -Rghc-timing -split-objs -c GHC/TopHandler.lhs -o GHC/TopHandler.o /var/tmp/portage/ghc-5.04/temp/ghc9723.hc: In function `s5tl_ret': /var/tmp/portage/ghc-5.04/temp/ghc9723.hc:246: warning: implicit declaration of function `writeErrString__' /var/tmp/portage/ghc-5.04/temp/ghc9723.hc: At top level: /var/tmp/portage/ghc-5.04/temp/ghc9723.hc:1319: conflicting types for `GHCziTopHandler_runNonIO_closure' /var/tmp/portage/ghc-5.04/work/stage2-build/ghc/includes/RtsAPI.h:126: previous declaration of `GHCziTopHandler_runNonIO_closure' /var/tmp/portage/ghc-5.04/temp/ghc9723.hc:1401: conflicting types for `GHCziTopHandler_runIO_closure' /var/tmp/portage/ghc-5.04/work/stage2-build/ghc/includes/RtsAPI.h:125: previous declaration of `GHCziTopHandler_runIO_closure' <<ghc: 69406916 bytes, 77 GCs, 2853367/4653256 avg/max bytes residency (4 samples), 13M in use, 0.04 INIT (0.01 elapsed), 4.46 MUT (9.38 elapsed), 3.27 GC (3.42 elapsed) :ghc>> I have the feeling that this error might disappear when building the latest sources using this approach. (The ebuild still uses 5.04.) I'll try this as soon as I get around to it.
Yes! I just built the 5.04.2 version of the ghc compiler manually, using the binary distribution of the same compiler. All I did was: ./configure --prefix=/usr/local/ghc make && make install and that was it. The only problem left now is that the build fails when I use the more aggressive configuration flags --enable-objectio --enable-hopengl as well -- then the build fails with a "missing import module" error, which seems to stem from something not being included in the distribution. I'll try to figure this out as well, but I guess that I won't be able to actually make a ebuild file for this beast ... So if anyone else would like to, I'd certainly appreciate it. :-)
Good news: The --enable-objectio flag to configure seems to be the one that made the last build fail, but the other features work. So to summarize: 1) I grabbed the 5.04.2 binary distribution from the vendor and installed it. 2) I grabbed the sources of the 5.04.2 version from the vendor. 3) I manually -- not via ebuild -- compiled the version as follows: ./configure --enable-hopengl --enable-threaded-rts make make install Obviously, GLUT must be installed for this to work. I didn't patch anything, didn't change anything, nothing. So I guess it would be fine to use this approach to build GHC via ebuild as well. Like I said, I cannot really make that ebuild file, because I don't know enough about Gentoo's build system, but IMHO modifying the current build file shouldn't be that much work for someone who knows what he's doing. I'll also contact the vendor about the failure when building with the objectio stuff; maybe they can provide some insight.
Hi Peter. Thanks for the instructions! I am doing slow progress towards sorting things out. First of all I decided to split ghc into ghc-bin and the actual ghc, which will be built from source and will depend on ghc-bin. This will simplify the bootstrapping logic which seems to be arch-dependent and quite involved in some cases. There is an additional benefit of letting people who would be willing to settle for i386 ptimized code to just grub the package and go, as ghc compile is quite big and resource-hungry from my experience. Thus I created dev-lang/ghc-bin and committed first ebuild there. It is x86 only a present. I'll add more arches later, when I will sort out the correct way to process SRC_URI's dependoing on arch. Please test. Some TODO (so that I don't forget it ;)): 1. sort out the correct way to do arch dependent SRC_URI's (the problem is if I just check arch and then specify SRC_URI, the mirrors are gonna be screwed. If I just put all versions in SRC_URI, users will have to download a lot of unnecessary stuff) 2. Create corresponding source ebuild 3. Make ghc-bin PROVIDE dev-lang/ghc or create a new virtual/ghc. This will let users choose to use ghc-bin in place of ghc to compile all utils and othe packages. George
Just curious: Is there any progress with the GHC package?
Hi guys. Sorry for prolonged delay. Back to this bug finally! I would like to spill out here my considerations regarding the PROVIDE: should it be dev-lang/ghc or virtual/ghc? From email I sent to -core: Now the consideration I am not certain about: I see in the policy, that a package should PROVIDE something under virtual/... unless it has been moved and tries to provide its previous incarnation. Well, this makes perfect sence for services (cron, etc.; AFAIR this was designed specifically for such situations), however in this case this may pose some problems. The ideal solution I can see is to make ghc depend on ghc-bin and make ghc-bin PROVIDE dev-lang/ghc. PROVIDE is essential here, because ghc is used by multiple packages (under dev-ml, there are quite a few more waiting for the situation with ghc to be sorted out). So, what bout making ghc and ghc-bin PROVIDE virtual/ghc? 1. It is less natral in this case, since ghc is a compile (and not a run-time, like cron) dependency. 2. More importantly, ghc-bin is awailable in the last version only for x86. Other arches should either use older (major) version of ghc-bin or be bootstrapped from that version (involving more bootstrap stages). This effectievly locks default PROVIDE in virtuals to virtual/ghc, as another variant is not consistent among arches (well, it just plainly can cause trouble), while 1st variant does not have this requirement (or at least is much softer on that). Now, this all does not take into account the following: There are packages that will rely on ghc to be installed, such as hmake, hdoc haddock and may be there were few more. ghc is not the only haskel compiler, so can these packages or are there other packages that may be compiled by not only ghc but for example nhc98 or hugs98? I am not too much into haskel field, so I am not too sure about differences/similarities between all these packages. What do you guys think? PS I am marking 6352 as a duplicate of this one, since it seems we have more substantial resolution here. George
*** Bug 6352 has been marked as a duplicate of this bug. ***
It does not seem to make much sense to me to create a virtual/ghc target just for the ghc <-> ghc-bin issue. Letting ghc-bin provide dev-lang/ghc seems more reasonable, because that reflects the fact that ghc-bin is a "shortcut" or "workaround" to get a working ghc in the first place. About the "multitude" of Haskell compilers: It might be worthwhile to consider creating a virtual/haskell or virtual/haskell98 target in the long run, because there are indeed packages that can be compiled by both GHC and nhc. The situation is quite complicated, though. I will try to explain: There is a language standard, called Haskell 98, which is more or less completely implemented by all GHC, nhc98, and hugs (although hugs in only an interpreter, not a compiler). However, most applications use some of the many language extensions that GHC implements and can thus only be compiled with GHC. Then again, nhc98 has recently gained some ground and implements some of those extensions as well. I would probably make GHC the default and don't create any virtual targets for now. Maybe a USE flag "nhc98" could be added to mean "use nhc98 to compile Haskell code whenever possible".
Hi Andres. Thanks for the clarification, this is pretty much what I was looking for. I think I'll create virtual/haskel then and set defaults to ghc-bin on x86 and if an update (below) works on sparc. Also I updated ghc-bin to support sparc and did a few fixups to make wrapper scripts in /usr/bin use correct paths. Testing is welcome! I need to know the results on sparc platform before I can proceed to ghc. If it works the ghc ebuild may become *very* simple. George
Hi guys. More progress on ghc. I just committed 5.04.2 version, which is completely redesigned and bootstraps off ghc-bin. As only two arches are supported (x86 and sparc) and both at present seem to have binary packages awailable (sparc people please test!) this should be pretty much it. My final decision was to bootstrap ghc off ghc-bin instead of making ebuild unpack and install binary image under $WORKDIR and going from there. Extract from the comment in ebuild: #Making ghc unpack binary build first (under ${WORKDIR}) and bootstrapping from that will effectively force #ghc-bin reinstall every time ghc is rebuilt or upgraded. What is worse it will likely force download of binary image #at upgrade, which is not nice (in fact quite bad for modem users - 16+ MB). # #The best results are achieved if ghc-bin is left alone after ghc installation - #Both ebuilds install in the same place, thus space penalty is minimal. In fact only the docs exist in double #(considering that ghc is not installing much docs at present this looks more like an advantage). #When the upgrade time comes, if you still have ghc-bin around, portage will happily bootstrap off #your existing ghc (or ghc-bin, whichever was merged last), without attempting to ruin anything... Additionally, I tried i dynamically checking awailablity of ghc, but that does not work well. emerge cannot be run from within another instance of portage (sandboxes would conflict), Dynamic dependency mangling is ignored and quite rightfully so, as this is not safe. Which only leaves two above possibilities. The ebuild is keymasked. Please test. George
Hi George, I did some testing, however only on x86 ... Unfortunately, the current solution is not yet perfect. At the moment, dev-lang/ghc depends on dev-lang/ghc-bin. First potential problem situation: I say "emerge ghc" which will install ghc-bin and then ghc. I will have a running and perfectly working version of ghc which is nicely bootstrapped. Then, someone discovers a typo or bug in the ghc-bin-ebuild and commits a new version. When I do an "emerge -u world" next time, ghc-bin will overwrite my ghc installation. I will still have a working ghc, but not the bootstrapped version anymore. Suggested solutions: (1) Create "virtual/ghc", as already discussed. Make "virtual/ghc" default to "dev-lang/ghc-bin" and make both "dev-lang/ghc" and "dev-lang/ghc-bin" provide "virtual/ghc". That works on my machine as desired, at least. (2) I do not know how PDEPEND works, and I did not test that yet. But it might be possible to let "dev-lang/ghc-bin" have a "PDEPEND" on "dev-lang/ghc". Therefore, in the situation above, "dev-lang/ghc" would at least be reinstalled after "dev-lang/ghc-bin" is updated. Second potential problem situation: If the versions of ghc-bin and ghc diverge for some reason (which is very likely, because source releases are much more frequent than binary ones -- there is a nightly unstable build, for example), then the current dev-lang/ghc ebuild won't build the ghc interpreter (ghci) anymore. The ghci is only working if ghc is bootstrapped with exactly the same version of itself, which is not true in the case that ghc-bin is older than ghc. Suggested solutions: (1) Re-include the appropriate check from the old ghc ebuild if the current GHC version number matches the version number of the build. If it does not, build twice, otherwise one build is enough. (2) Use a ghc-5.05 source tarball. The Makefile of 5.05-versions has targets that automatically recompile ghc multiple times. If I find more time, I might try to actually create a pair of ebuild implementing my suggestions, but I can't promise that yet. Best, Andres
Hi Andres. Thanks for the checks and reply! Looks like I missed it due to bugzilla temporarily not sending out notification emails :(. (fixed now). On the highlighted problems. first one: yes, #1 was my plan ;), I just wanted to get some test reports before I make any official changes in virtuals and start processing all the ghc based tools/packages. second one: ok, that is a problem and again #1 sounds like a plan :). As I understand 5.05 is not stable yet? In such case I would prefer going route 1. I'll modify ebuild accordingly and will ask you guys to check it. If it passes ;), I will create virtuals and start on haddock, hmake and hdoc. George
Hi guys. Ok, the update is up. Please test. The modifications should cure the problem#2 mentioned by Andres. If this tests out Ok, I'll create virtuals and close-up the #1 issue. George
Hi George, I tested the new build and it failed. However, nothing really serious. I will attach a diff that makes it work for me. I am not sure about the things you do with the ghcprof script, but because I do not use it, I do not care for now ;-) Andres
Created attachment 9253 [details, diff] patch for the current ghc ebuild
The 5.04.2 fell over (after an hour or so) with the following error: ------------------------------------------------------------------------ ===fptools== Finished making `all' in DrIFT DtdToHaskell Xtract ... PWD = /var/tmp/portage/ghc-5.04.2/work/stage2-build/hslibs/tools ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make all -wr; in /var/tmp/portage/ghc-5.04.2/work/stage2-build/hslibs/doc ------------------------------------------------------------------------ make[2]: Nothing to be done for `all'. ------------------------------------------------------------------------ ===fptools== Finished making `all' in lang concurrent posix util data text net hssource tools doc ... PWD = /var/tmp/portage/ghc-5.04.2/work/stage2-build/hslibs ------------------------------------------------------------------------ make[1]: Leaving directory `/var/tmp/portage/ghc-5.04.2/work/stage2-build/hslibs' /var/tmp/portage/ghc-5.04.2/work/ghc-5.04.2 >>> Install ghc-5.04.2 into /var/tmp/portage/ghc-5.04.2/image/ category dev-lang mk/boilerplate.mk:48: mk/config.mk: No such file or directory You haven't run ./configure yet. make: *** [mk/config.mk] Error 1 !!! ERROR: dev-lang/ghc-5.04.2 failed. !!! Function src_install, Line 4, Exitcode 2 !!! (no error message) Tried running it twice to verify that it was a 'real' failure.
Hi Mikael, your problem seems to be one of the things that my little patch should fix. The cause is that in the src_install procedure the current directory has to be changed to the stage 2 build tree. However, in the meantime I noticed more, so I will provide an updated patch (still against the ebuild that is in Portage right now). Tomorrow I will check if the ebuild works with 5.04.3 which has been released yesterday. Andres
Created attachment 9299 [details, diff] new patch for the current ghc ebuild
Hi Andres. Thanks for catching those typos! I have updated the ebuild. Will add virtuals soon and then test and add 5.04.3. Uff, this seems to clear-up finally :). George
Good news! On my machine, the current ebuild works unchanged for 5.04.3. I did not test ghc-bin, though ... Andres
Hi Andres. Thanks for testing! Looks like bugzilla was not sending notifications for a day or too, so unfortunately I saw your report only now :(. I created new virtual - virtual/ghc and set its default to dev-lang/ghc-bin as was discussed previously. I also modified the ebuilds - ghc-5.04.2 and ghc-bin-5.04.2 and created a ghc-5.04.3.ebuild. So, this finally should resolv this bug and update ghc to the latest available. Please test. George
Just curious: Is anybody reading the gentoo-developers mailing list? I am asking because I have some general comments concerning the future of Haskell support in Gentoo and wonder, whether posting them to this list will reach the intended audience or not. (I prefer mail to web-based messaging.)
I am reading gentoo-dev. I would be interested to discuss the future of Haskell in Gentoo as well. I would also like to help implementing whatever solution we might find. Best, Andres
Hi Peter and Andres. Well, I do as well, and would be interested in hearing the proposals. Not sure -dev is the best place (I would not expect that many readers of -dev to be interested in haskel or the other way around), but I cannot think of a better place anyway. Right now ghc seems to be working ok at least on x86. I have something like 3 packages for ghc in portage (##3970, 4025, 12836), which I'll start processing after I get done with some more "real" bugs. One question I have is, for which of these packages some other haskel compiler can be substituted. We have hugs98 and nhc98 as alternatives. The idea is to have virtual/haskell and have packages that are "compilant" to depend on it. However realistically speaking looks like majority of packages require ghc... Anyway, this will have to be decided on a per-package basis, asking submitters for what they know about the package. Though so far I am not sure there are enough packages that would validate new virtual (i.e. would compile by multiple haskell implementations). Just a quick thought :). George
OK. I'll post an article with a couple of questions to discuss to the -dev list then. Even if the rest of the list does not care about Haskell, maybe they can contribute ideas in general concerning the integration in Gentoo. See you there! Peter
By the way: nhc98 version 1.16 does work with gcc 3.x now. I managed to build it on my machine without _any_ problem (using ghc to compile it) and am quite impressed with how small the resulting binaries are compared to the ones ghc produces. Any chance of getting an ebuild file for nhc98 as well? :-)
Hi guys. I have moved ghc-bin and ghc (both 5.04.2 and .3) to stable profile on x86 (sparc needs some testing). It's about time to start on haskell based packages :).. Peter: Thanks for starting that discussion on -dev. I remember posting a comment to this bug about the same time, however I do not see it here :(. Anyway, that was pretty much along the lines of what you said on the mailing list. Of the all proposed resolutions I am starting to like the most the last one - namely to have a virtual and make packages that can be compiled by either ghc or nhc depend on it and than use haskellc-config (for example) to set "active" compiler. My understanding is that such packages will use some special var (HC?) to be able to use generic haskell compiler, so this should be easy to tie to haskellc-config, or they might even have a configure flag. The tuoghest one is if they just check for both compilers in certain order (though I would consider this approach as essentially "broken", but everything might happen), but even this should be workable.. The ones that require specific compiler will use the correct binary anyway, so I think both should be available in the $PATH and symlinks or env vars will have to be mangled. >By the way: nhc98 version 1.16 does work with gcc 3.x now. I managed to build >it on my machine without _any_ problem (using ghc to compile it) and am quite >impressed with how small the resulting binaries are compared to the ones ghc >produces. > >Any chance of getting an ebuild file for nhc98 as well? :-) Some more details please ;)? Like was that just a standard procedure that you followed, or is there anything else? Actually the best way to go is if you would submit a bug (assign directly to me) with a request ;), so that I don't forget about it. You may also put some summary on the above discussion in that bug - it really only makes sence when we get nhc working.. Now closing this bug. George
Hi there, I am still not convinced that there should be a virtual target plus config tool. First of all, there are not many programs that can be compiled with both nhc98 and ghc. Then, these are the only two compilers, and probably will be for quite some time. It is likely that more compilers will be around, but these will probably be even more specialized and tied to specific projects. A config-tool has to be written, and even though it is easy to write, it has to be maintained and is a potential source of bugs. AFAIK, there is no general solution for config-tools in Gentoo yet, although there are several packages having such programs (java-config, gcc-config, ...). As a quick solution, I would prefer the use-flag that allows the express preference for nhc98. That way, ghc is the default, as it will be for most users. This does not cause any additional work to be done right now and allows us to quickly increase the number of Haskell-related packages in Gentoo. Once we have a large number, we could reevaluate the situation. I would like the dev-haskell category to be created and the ebuilds that are already in the pipeline (such as happy or haddock) to be processed. I will try to help by updating existing ebuilds and creating more. Should I generally assign Haskell-related bugs directly to you, George? Best, Andres
Concerning nhc98: I I have created a new PR, which is available at: http://bugs.gentoo.org/show_bug.cgi?id=18857 As for the future integration of Haskell into Gentoo: I'll post some comments to the -dev mailing list ASAP.
Hi guys. Andres: ok, lets go on with just a use flag for now. If we'll get upwards of 3 to 5 "generic hasekll" ebuilds though we should start thinking about implementing a "real" solution as was discussed. On the category: there already exists dev-ml, which only has 7 packages at the moment. As i remember it was called dev-ml rather than dev-ocaml to sound more generic since it was supposed to hold haskell-related stuff as well. I'll start putting haskell packages in it, unless everybody thinks this is absolutely inappropriate (but please substantiate the claims then). Added two more "blocked" bugs, to keep track of what's in the bugzilla at the moment. George
I think dev-ml is quite inappropriate for Haskell-related stuff. It might be comparable in putting Eiffel tools into dev-pascal or python tools into dev-perl. The name dev-ml is certainly "generic" in the way that it is good enough for both SML and O'Caml and other ML-dialects. The only thing that the ML-family has in common with Haskell is that both languages are functional languages. So, if all these packages have to go into one common category for some reason, I would at least suggest renaming that category to "dev-functional". Another argument against "dev-ml", apart from inappropriateness, is that nobody looking for a Haskell tool would look in "dev-ml". I am quite optimistic that we will end up with more than five Haskell items at least, if not more. If there is no real argument against a new category, I would favor creating "dev-haskell". The name is unlikely to collide with anything else, at least. Best, Andres
I just installed ghc 5.04.3 AND nhc98 1.16 successfully via portage. Worked just fine. I have one question, though: Is there any attempt to deal with registering packages with the compiler in portage? Or am I on my own? :-)
Hi guys. Andres: These arguments seem reasonable, however new category has to be approved. I will go ahead and send out a proposal, but before that I would need a "head count" of how many packages are we going to have in the category. Right now I see only 3 packages, as per this bug dependencies. If we are going to get more submitted, then I guess new category can be warranted. Alternatively I can start putting already submitted packages in dev-ml and if we get more afterwards (say 5 total) I will create a new category and move them over. Peter: Thanks for testing! Also I did not quite understand what did you mean in the last part of the message - regarding "registering packages with the compiler in portage". Could you please elaborate? George
Additional packages that I envision to be in Gentoo soon (depending on me or others having time to write ebuilds, of course): dev-haskell/frown A parser generator, similar to happy. dev-haskell/gh Generic Haskell compiler. A language extension for Haskell. dev-haskell/uust University of Utrecht Software Technology tools package for GHC. dev-haskell/lhs2TeX (Could maybe go into other categories as well). Format Haskell code for typesetting with LaTeX. (There are similar other tools.) dev-haskell/arrows Arrow notation preprocessor. dev-haskell/helium A compiler for a Haskell-related language. Could also go to dev-lang. This one is already submitted as bug 14671, but has not been included yet. dev-haskell/yampa An implementation of Arrowized Functional Reactive Programming for Haskell. dev-haskell/fmp Functional Metapost. An embedding of the Metapost language into Haskell. dev-haskell/hgl Hugs graphics library. (There are several graphics libraries for Haskell that could be incorporated.) dev-haskell/wash HTML/CGI combinator libraries. dev-haskell/haxml XML tools for Haskell. dev-haskell/thih Typing Haskell in Haskell. A reference typechecker for Haskell written in Haskell. dev-haskell/aterm Library to read and write ATerms. dev-haskell/drift Automatic generation of type class instances. Point of the exercise: The potential is certainly there. I will try to work slowly, but steadily towards this goal by submitting new ebuilds. Now that the basics seem to become stable (compilers working, category discussions ...), things become easier. About the packages: As I understand Peter, he means the following: GHC (I don't know about nhc98, actually) has a package system. GHC automatically installs a separate tool ghc-pkg, that can be used to add and configure packages. Packages are precompiled sets of Haskell modules that can be easily included into different projects. Some of the ebuilds I mentioned above would actually constitute new GHC packages. Packages, when installed, have to be registered by using ghc-pkg, and, unfortunately, all packages have to be re-registered when GHC is updated. Incidentially, I just today spent a little bit of time thinking about this problem. I think it is somewhat related to the problem of, for instance, installing Emacs Lisp packages for Emacs. What I would suggest is writing an eclass ghc-package. This eclass would set an environment variable GHC_PKG_DIR=/usr/share/ghc-pkg and an update function ghc_regenerate_packages. All packages and GHC itself (which also comes with a set of predefined packages) would install their package data into ${GHC_PKG_DIR}. The function ghc_regenerate_packages would automatically be called in pkg_postinst and pkg_postrm or at least be provided by the eclass. The function would scan the directory, and issue a set of appropriate ghc-pkg calls to bring the package file up-to-date. This way, one always has an up-to-date GHC package configuration file. Do I miss something? If not, I could write the eclass and submit a demonstration ebuild which would probably be the dev-haskell/uust mentioned above. Best, Andres
Andreas described GHC's (and nhc98's) package system pretty well. Yes, that is what I was thinking of when asking about "packages". Apparently, ghc supports a "local package config" in addition to the system-wide one. If we could maintain a package config for GHC in, say, /etc/ghc/package.conf and use some environment variable to tell GHC to load this file as well, we shouldn't run into problems when updating GHC -- the local package config should be unaffected. The only problem is: There appears to be no way to set the "-package-conf" option via the environment. :-( I'll ask the GHC developers about this and will report my findings.
Hi Peter. I will have to look more closely on nhc98's package system. I have to admit that I never used it (yet). Do you know if there is something like "ghc-pkg" for nhc98? It does not seem so. If not, what causes a package being recognized as one? As for GHC, the method you propose is very much like the one I had in mind. There is AFAIK no environment var for the package-conf file, but that is not a problem as GHC is installed to be called by a wrapper script anyway. It should be easy to modify the GHC ebuild and make it use the package config files we want it to see ... Andres
No, in nhc98 there is nothing like ghc-pkg. There you "register" a package by copying the interface files to /usr/include/nhc98/pkgname and by copying the linked library to /usr/lib/nhc98/architecture.
I wrote: > ghc supports a "local package config" in addition to the > system-wide one. If we could maintain a package config for > GHC in, say, /etc/ghc/package.conf and use some environment > variable to tell GHC to load this file as well, we shouldn't > run into problems when updating GHC -- the local package > config should be unaffected. I promised to ask the GHC developers about this and here is what they replied: | We've avoided envt variables (and .ghcrc files) so far, because | it's one more thing we have to ask about when responding to bug | mail. You can always make yourself a little shell script for | my_ghc, or a shell alias. So obviously, there is no environment variable we can set in order to use our own pgk-config file in addition to the GHC-specific one. Wrapping the ghc call into a script that passes the command line parameters appropriately is probably the best solution. Clearly, this will require some though and experimentation. :-|
Hi Peter, I still not really see why an environment var would have been easier than a command line parameter (personally, I do not like env vars too much). Thanks in any case for asking on the mailing list, though. It's always good to know all the options. The package system will probably haunt me for a long time now ;) Right at the moment, the issues with the package system can probably not be resolved completely satisfactory within Gentoo, as at least GHC's packages are binary incompatible between versions. Thus, they need to be rebuilt every time GHC is upgraded. This is possible with either conditional or reverse dependency checking, both of which are _planned_ for portage (post Gentoo 1.4), but not yet implemented. Therefore, in the coming weeks I will see what I can do about all the non-package Haskell-related ebuilds. I will probably start with the ones already in Bugzilla, finally moving happy into the tree, and haddock, and hmake. For the latter I will probably create an own ebuild and remove it from the nhc98 ebuild in turn. Once all this is cleanly done, I will look at the packages again, and who knows, maybe portage has some nice features more until then ... Best, Andres
Reclosing the bug
