can't build haxml under ghc 6.7, says HughesPJ is hidden... but ghc-pkg doesn't say it's hidden...
Can I get some help building HaXml (from hackage) under ghc 6.7? I'm hoping to get HAppS running under 6.7, and use the new debugger to better understand what's going on under the hood. Eg, when I'm in the h function, I can take a look at the args and just see what types they are. (I am finding building an intuition from the documentation alone to be overwhelming. Too many types, too many instances... total confusion.) HaXMl is a dependendency for happs, that's why I need it. Anyway building haxml this is what I get. The subject of my message more or less summarizes my confusion. hartthoma@linuxpt:~/installs/HaXml-1.13.2>runghc Setup.hs build Setup.hs: Warning: The field "hs-source-dir" is deprecated, please use hs-source-dirs. Preprocessing library HaXml-1.13.2... Preprocessing executables for HaXml-1.13.2... Building HaXml-1.13.2... src/Text/XML/HaXml.hs:30:7: Could not find module `Text.PrettyPrint.HughesPJ': it is a member of package pretty-1.0, which is hidden hartthoma@linuxpt:~/installs/HaXml-1.13.2>ghc-pkg list /usr/local/lib/ghc-6.7.20070719/package.conf: Cabal-1.1.7, base-2.1, directory-1.0, filepath-1.0, ghc-6.7.20070719, haskell98-1.0, hpc-0.5, old-locale-1.0, old-time-1.0, pretty-1.0, process-1.0, random-1.0, readline-1.0, rts-1.0, template-haskell-0.1, unix-2.0 hartthoma@linuxpt:~/installs/HaXml-1.13.2>ghc-pkg list pretty-1.0 /usr/local/lib/ghc-6.7.20070719/package.conf: pretty-1.0 hartthoma@linuxpt:~/installs/HaXml-1.13.2>ghc --version The Glorious Glasgow Haskell Compilation System, version 6.7.20070719 hartthoma@linuxpt:~/installs/HaXml-1.13.2>ghc-pkg describe pretty-1.0 name: pretty version: 1.0 license: BSD3 copyright: maintainer: libraries@haskell.org stability: homepage: package-url: description: This package contains a pretty-printing library. category: author: exposed: True exposed-modules: Text.PrettyPrint Text.PrettyPrint.HughesPJ hidden-modules: import-dirs: $topdir/lib/pretty-1.0 library-dirs: $topdir/lib/pretty-1.0 hs-libraries: HSpretty-1.0 extra-libraries: extra-ghci-libraries: include-dirs: $topdir/lib/pretty-1.0/include includes: depends: base-2.1 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: $topdir/share/ghc/doc/html/pretty/pretty.haddock haddock-html: $topdir/share/ghc/doc/html/pretty hartthoma@linuxpt:~/installs/HaXml-1.13.2> hartthoma@linuxpt:~/ProjectRepos/miscAdmin>ghc-pkg list /usr/local/lib/ghc-6.7.20070719/package.conf: Cabal-1.1.7, base-2.1, directory-1.0, filepath-1.0, ghc-6.7.20070719, haskell98-1.0, hpc-0.5, old-locale-1.0, old-time-1.0, pretty-1.0, process-1.0, random-1.0, readline-1.0, rts-1.0, template-haskell-0.1, unix-2.0 --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
On Thu, Aug 09, 2007 at 06:40:47PM -0400, Thomas Hartman wrote:
Can I get some help building HaXml (from hackage) under ghc 6.7?
I'm hoping to get HAppS running under 6.7, and use the new debugger to better understand what's going on under the hood. Eg, when I'm in the h function, I can take a look at the args and just see what types they are. (I am finding building an intuition from the documentation alone to be overwhelming. Too many types, too many instances... total confusion.) HaXMl is a dependendency for happs, that's why I need it.
Anyway building haxml this is what I get. The subject of my message more or less summarizes my confusion.
You're encountering one of my favorite features of Cabal. When you build a package, Cabal passess the -hide-all-packages option to GHC, which prevents the package from using any installed packages other than the ones explicitly listed in the Build-Depends: field. This is a Good Thing, because it means that whether or not a package builds depends *only* on the versions of the Build-Depended packages; other random packages on your system cannot possibly have any effect. Unfortunately, it means that splitting an existing package (base -> base + pretty + directory + old-time, with much more to come) is less than transparent; all packages which use HughesPJ need their Build-Depends field modified to include pretty, etc. Thomas Schilling's "configurations" allows a package to build with split and unsplit bases, but requires the logic to handle this be present in every package that wants to use base, and is only in HEAD cabal. I personally advocate a Debian-style system of Provides and re-exposing, but haven't yet bothered to actually implement it at all. I'm sure other people have other approaches. For now, we just edit .cabal files when transporting code between GHC versions... Stefan
Stefan O'Rear
When you build a package, Cabal passess the -hide-all-packages option to GHC, which prevents the package from using any installed packages other than the ones explicitly listed in the Build-Depends: field.
For now, we just edit .cabal files when transporting code between GHC versions...
Just for information, the HaXml darcs repo has recently adopted the solution of containing two .cabal files, one for ghc-6.6.x, and the other for the split-base packages (>=ghc-6.7). The only difference is the build-depends line, which is now as follows: build-depends: base, haskell98, polyparse, pretty, fps But if you have collected the earlier release HaXml-1.13.2 from hackage, then you can omit both 'polyparse' and 'fps' dependencies. ('fps' will shortly be changing to 'bytestring' in any case...) Regards, Malcolm
For now, we just edit .cabal files when transporting code between GHC versions...
Just for information, the HaXml darcs repo has recently adopted the solution of containing two .cabal files, one for ghc-6.6.x, and the other for the split-base packages (>=ghc-6.7). The only difference is the build-depends line, which is now as follows:
build-depends: base, haskell98, polyparse, pretty, fps
But if you have collected the earlier release HaXml-1.13.2 from hackage, then you can omit both 'polyparse' and 'fps' dependencies. ('fps' will shortly be changing to 'bytestring' in any case...)
would it be possible to put more emphasis on continuity in haskell (just as there should be an emphasis on portability;-)? when changing language, tools, or libraries in a way that breaks existing programs, deprecating the old api for one version before removing it is rarely sufficient, and leads to breakage rather than hackage.. it would be nice if anyone thinking of breaking a public api would spend some thought on code transitions. be it by providing compatibility adapters, or code transformations, or whatever. users should not be so accepting of breaking changes, either. yes, you may be able to work around the issues, but what good are package managers if they only work with workarounds? in this particular case, the rest-base simply doesn't do what base did, so it shouldn't be named base. instead, perhaps there should be a virtual base package that only tracks the dependencies needed to support the old base? similarly for the now-its-in-now-it-isnt fps/bytestring. :-) claus
so you get
$ runghc Setup.hs configure
Setup.hs: Multiple description files found. Please use only one of :
["HaXml.cabal","HaXml-darcs.cabal"]
is there a way to specify which cabal file should be used, or do you just
have to move a file out out the way with eg
mv HaXml.cabal HaXml.cabal.tmp ?
Understanding this better is important to me because I am installing a
number of packages on 6.7, and am reluctant to send a patch that breaks
backwards compabitility with earlier versions.
It seems to me that if there is a way to specify the cabal file, you're a
step closer to having something DWIM that works for either 6.6 or 6.7, as
Claus wishlists elsewhere in this thread.
thomas.
Malcolm Wallace
When you build a package, Cabal passess the -hide-all-packages option to GHC, which prevents the package from using any installed packages other than the ones explicitly listed in the Build-Depends: field.
For now, we just edit .cabal files when transporting code between GHC versions...
Just for information, the HaXml darcs repo has recently adopted the solution of containing two .cabal files, one for ghc-6.6.x, and the other for the split-base packages (>=ghc-6.7). The only difference is the build-depends line, which is now as follows: build-depends: base, haskell98, polyparse, pretty, fps But if you have collected the earlier release HaXml-1.13.2 from hackage, then you can omit both 'polyparse' and 'fps' dependencies. ('fps' will shortly be changing to 'bytestring' in any case...) Regards, Malcolm _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
I wrote:
Just for information, the HaXml darcs repo has recently adopted the solution of containing two .cabal files, one for ghc-6.6.x, and the other for the split-base packages (>=ghc-6.7).
Thomas Hartman
$ runghc Setup.hs configure Setup.hs: Multiple description files found. Please use only one of : ["HaXml.cabal","HaXml-darcs.cabal"]
is there a way to specify which cabal file should be used, or do you just have to move a file out out the way?
For now, the latter (remove the unneeded file). Ultimately, the use of "Cabal Configurations" will allow us to revert to a single .cabal file with sections conditional on the compiler version.
Understanding this better is important to me because I am installing a number of packages on 6.7, and am reluctant to send a patch that breaks backwards compabitility with earlier versions.
Multiple .cabal files are just a temporary measure for development ease. Neither ghc-6.7 nor this version of HaXml have been released officially, so you should not rely on any particular behaviour. Regards, Malcolm
participants (4)
-
Claus Reinke -
Malcolm Wallace -
Stefan O'Rear -
Thomas Hartman