July 2007 - cabal-devel

Cabal, haddock and functorm-1.0.1 problem
by Sascha Böhme 24 Jul '07

24 Jul '07

Hello, when generating Haddock documentation of functorm-1.0.1 via runhaskell, no description for module Data.FunctorM is generated. However, when running Haddock manually and omitting to read the base interface, documentation is generated, although it lacks (naturally) the links to some elements of base. What could go wrong here? What might be the problem? Below are the outputs of runhaskell and the manual run of Haddock. Thanks, Sascha $ runhaskell Setup.lhs configure --prefix=/home/user5 configure: Reading installed packages... Configuring functorm-1.0.1... configure: Dependency base-any: using base-2.0 configure: Using install prefix: /home/user5 configure: Binaries installed in: /home/user5/bin configure: Libraries installed in: /home/user5/lib/functorm-1.0.1/ghc-6.6 configure: Private binaries installed in: /home/user5/libexec configure: Data files installed in: /home/user5/share/functorm-1.0.1 configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.6 configure: Using package tool: /usr/bin/ghc-pkg configure: Using ar found on system at: /usr/bin/ar configure: Using haddock found on system at: /usr/bin/haddock configure: Using ld found on system at: /usr/bin/ld configure: No pfesetup found configure: Using ranlib found on system at: /usr/bin/ranlib configure: Using runghc found on system at: /usr/bin/runghc configure: No runhugs found configure: Using tar found on system at: /bin/tar configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: No c2hs found configure: Using cpphs: /usr/bin/cpphs configure: No greencard found $ runhaskell Setup.lhs haddock -v Creating dist/build/tmp (and its parents) Creating dist/doc/html/functorm (and its parents) Preprocessing library functorm-1.0.1... Running Haddock for functorm-1.0.1... /usr/bin/haddock --version /usr/bin/ghc-pkg field base-2.0 haddock-interfaces /usr/bin/ghc-pkg field base-2.0 haddock-html Creating dist/build/tmp/./Data/ (and its parents) /usr/bin/haddock --html --odir=dist/doc/html/functorm --title=functorm-1.0.1: Data.FunctorM (compatibility package) --package=functorm-1.0.1 --dump-interface=dist/doc/html/functorm/functorm.haddock --prologue=functorm-1.0.1-haddock-prolog.txt --read-interface=/usr/share/ghc-6.6/html/libraries/base,/usr/share/ghc-6.6/html/libraries/base/base.haddock dist/build/tmp/./Data/FunctorM.hs $ ls dist/doc/html/functorm/ doc-index.html functorm.haddock haddock.css haddock.js haskell_icon.gif index.html minus.gif plus.gif $ /usr/bin/haddock --html --odir=dist/doc/html/functorm --title=functorm-1.0.1: Data.FunctorM (compatibility package) --package=functorm-1.0.1 --dump-interface=dist/doc/html/functorm/functorm.haddock dist/build/tmp/./Data/FunctorM.hs Warning: Data.FunctorM: the following names could not be resolved: Monad Maybe Ix Array $ ls dist/doc/html/functorm/ Data-FunctorM.html doc-index.html functorm.haddock haddock.css haddock.js haskell_icon.gif index.html minus.gif plus.gif

2 1

new target ./setup plain_source?
by Marc Weber 24 Jul '07

24 Jul '07

Hi. What about adding another target ./setup plain_source which should preprocess everything (including cpp) and output the files to an extra directory? Why? This could be used for haddock documentation generation (Not sure how this is done) and perhaps to be read by future IDE's to provide compiler independent completion etc? eg ./setup haddock on haddock sources itself fails on line #if defined(mingw32_HOST_OS) ... What do you think? Marc Weber

6 8

Proposed download version ? 0.0 better than 0.1?
by Marc Weber 23 Jul '07

23 Jul '07

I don't know the internals of hackage very well, but I think the most up to date version should be shown first? Example where its not the case: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/TypeCompose-0.0 Marc Weber

2 1

design question
by Sascha Böhme 18 Jul '07

18 Jul '07

Hello, in Distribution.PackageDescription, one library may be given, but in Distribution.InstalledPackageInfo, several libraryDirs, importDirs, includeDirs, haddockInterfaces, haddockHTMLs may exist. Why is this? How could there be more than one of these paths if there is just one library? I'm sure I miss some critical design decision. Thanks, Sascha

3 2

Re: [Haskell-cafe] When is extra-libraries config in .cabal
by Duncan Coutts 13 Jul '07

13 Jul '07

On Fri, 2007-07-13 at 12:05 -0400, Edward Ing wrote: > I am building and running some haskelldb/HDBC/HSQL libraries on > Windows XP (using the MinGW minimals system (MSYS)) with GHC > environment. > > I ran into runtime link problems, foreign functions would not found. > eg. atoi,from C standard; recv from sockets. > > To solve the problem, I added dll's to the build configuration field > "extra-libraries", MSVCRT (c runtime), KERNEL32, WSOCK32 (sockets). > This solved the problem. > > 1. But is there a better way to solve the problem? I am expecting that > those libraries are available through the OS and do not need explicit > loading. I am confuse by what does the loading of the libraries. > 2. Does a UNIX/POSIX system not have this problem? On unix the C compiler generally links to the standard C library without you having to ask for it explicitly. I'm not sure that if we automatically linked to msvcrt that everyone would be happy. Many people seem to think msvcrt is to be avoided in preference of 'native' win32 calls. > Information for understanding this problem would be great. This is a slightly tricky problem because the names of the libraries to link to are different on different operating systems. We don't have a proper solution to this at the moment. I'm posting this to the cabal-devel list in case anyone has any good practical realistic suggestions. Duncan

1 0

Cabal, Haddock, and the location of documentation - from Matthias Kilian
by Isaac Potoczny-Jones 12 Jul '07

12 Jul '07

Date: Sun, 8 Jul 2007 22:23:25 +0200 > From: Matthias Kilian <kili(a)outback.escape.de> > To: Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> > Cc: cabal-devel(a)haskell.org > Message-ID: <20070708202325.GA13943(a)petunia.outback.escape.de> > Subject: Re: [Haskell] Cabal, Haddock, and the location of documentation > > On Sun, Jul 08, 2007 at 06:22:43PM +0100, Duncan Coutts wrote: > > > I think it'd be perfectly reasonable to follow the lead of autoconf here > > > and have slightly finer grained control with respect to the kinds of > > > files we're installing. Autoconf distinguishes docs (and various kinds > > > of docs, html, ps, pdf, man etc) from the generic datadir. > > > > > > So yes, if you want to extend cabal in this direction I'm happy to > > > review patches. > > Ok, I'll give it a try, but it'll take a while (a week or two). > First I've to get all the OpenBSD ports updated (including horrible > workarounds for the missing docdir option). Everything else would > be maintainance hell for me ;-) > > Anyway, what are the requirements/whishes? > > - Just docdir, maybe htmlsubdir or haddocksubdir > - Or docdir and separate htmldir / haddockdir > - Something more flexible > > Ciao, > Kili

1 0

Windows line endings in .cabal file goes wrong
by Neil Mitchell 11 Jul '07

11 Jul '07

Hi When installing a .cabal package which has Windows line endings, the executable name is read as file^M. There are a few possible solutions: 1) Ban \r from .cabal files - cabal-upload should check this if this choice is made. 2) Cope with \r, a simple filter (/= '\r') should be sufficient. Thanks Neil

2 2

packages assigned more than one category / intentionally?
by Marc Weber 11 Jul '07

11 Jul '07

The following packages are listed more than once: "Crypto" "GuiTV" "TypeCompose" "Win32" "binary" "polyparse" That's not by accident, is it?

2 1

CMod Cint ? Some broken packages
by Marc Weber 11 Jul '07

11 Jul '07

The following packages (not including those which I couldn't build yet because I han't add missing C dependencies etc) are broken: log-hackage-BerkeleyDB-0.2: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-FileManip-0.2: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-HSH-1.2.0: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-darcs-buildpackage-0.5.11: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-debian-1.2: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-dfsbuild-0.99.4: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-flock-0.1: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-gopherbot-0.1.0: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-harchive-0.2: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-hg-buildpackage-1.0.1: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-hmp3-1.2: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-srcinst-0.8.7: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-unix-2.0: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-vty-3.0.0: Couldn't match expected type `CInt' against inferred type `CMode' log-hackage-xmobar-0.5: Couldn't match expected type `CInt' against inferred type `CMode' Should we built some replace support into cabal to make things just work for everyone? A simple table such like replace [ghc, '>6.61', 'CMod' ,'Cint'] would suffice .. ? Marc Weber

3 2

darcs patch: Add modules to cabal-setup.cabal: this makes Setup sdi...
by sjanssen＠cse.unl.edu 10 Jul '07

10 Jul '07

Tue Jul 10 13:13:42 CDT 2007 Spencer Janssen <sjanssen(a)cse.unl.edu> * Add modules to cabal-setup.cabal: this makes Setup sdist work

2 1