- cabal-devel - Haskell.org

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

24 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 14 Jul '07

14 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 13 Jul '07

13 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 11 Jul '07

11 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

Haddock support / tell ./setup where to find documentation of dependencies
by Marc Weber 11 Jul '07

11 Jul '07

I'm packaging all hackage packages for nix. I've already compiled 102 packages succesfully. Is there a simple way to do a ./setup haddock --dirs-containing-dep-docs=path1;path2;path3;path4 .. --install-to $out/haddock ? If not who is working on haddock stuff right now? Marc

1 0

Re: [Haskell] Cabal, Haddock, and the location of documentation
by Duncan Coutts 09 Jul '07

09 Jul '07

On Sun, 2007-07-08 at 22:23 +0200, Matthias Kilian wrote: > 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 The last comment in bug #140 from Ross seems a sensible suggestion. http://hackage.haskell.org/trac/hackage/ticket/140 haddockPref determines where the documentation is built; mkHaddockDir says where it is installed, currently $datadir/$datasubdir/doc/html/$pkg, where $datasubdir defaults to $pkgid. That default doesn't seem right in any case. Perhaps we want --docdir (defaulting to $prefix/share/doc on Unix and something else on Windows) --htmlsubdir (defaulting to $pkgid/html) Duncan

1 0