January 2009 - cabal-devel

patch applied (cabal): Typo in docs for source-repository
by Duncan Coutts 21 Jan '09

21 Jan '09

Wed Jan 21 14:07:47 PST 2009 Joachim Breitner <mail(a)joachim-breitner.de> * Typo in docs for source-repository M ./doc/Cabal.xml -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090121220747-23c07-78ab5ed2…

1 0

darcs patch: Typo in docs for source-repository
by Joachim Breitner 21 Jan '09

21 Jan '09

Hi, just a small typo that made me read that sentence thrice until I got it. Greetings, Joachim Wed Jan 21 23:07:47 CET 2009 Joachim Breitner <mail(a)joachim-breitner.de> * Typo in docs for source-repository

2 1

[Hackage] #179: support GHC's main-is extension
by Hackage 20 Jan '09

20 Jan '09

#179: support GHC's main-is extension --------------------------+------------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | --------------------------+------------------------------------------------- Query on haskell-cafe: http://haskell.org/pipermail/haskell- cafe/2007-November/034686.html {{{ It seems the meaning of the -main-is switch for GHC and the Main-Is build option for Cabal executables differ. With GHC, I can point to any function "main" in any module, but in Cabal I must point to a filename with precisely the module name "Main". This is tying my hands with regard to organizing a default executable and exposing some of its functionality as a library. Is there a way to get around this restriction? Concretely, I want to point Cabal's Main-Is to Program/Main.hs which starts with module Program.Main where instead of just module Main where }}} So in GHC it has this meaning: http://haskell.org/ghc/docs/latest/html/users_guide/options-phases.html #options-linker {{{ -main-is thing The normal rule in Haskell is that your program must supply a main function in module Main. When testing, it is often convenient to change which function is the "main" one, and the -main-is flag allows you to do so. The thing can be one of: A lower-case identifier foo. GHC assumes that the main function is Main.foo. An module name A. GHC assumes that the main function is A.main. An qualified name A.foo. GHC assumes that the main function is A.foo. }}} In Cabal the {{{main-is:}}} field specifies the '''file name''' of the Main module. GHC's {{{-main-is}}} flag is an extension to Haskell that is not supported by the other Haskell implementations. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/179> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

Main-Is not creating executable
by Alistair Bayley 20 Jan '09

20 Jan '09

I have this in Takusen.cabal: Executable miniunit_tests Main-Is: Test/MiniUnit/Main.hs Build-Depends: base, mtl Extensions: CPP CPP-Options: "-DNEW_EXCEPTION" (as well as the Library section). When it builds, the modules compile fine, but then I get: Warning: output was redirected with -o, but no output will be generated because there is no Main module. The ghc command (from setup -v build): Building executable: miniunit_tests... Creating dist\build\miniunit_tests (and its parents) Creating dist\build\miniunit_tests\miniunit_tests-tmp (and its parents) c:\ghc\ghc-6.10.1\bin\ghc.exe -o dist\build\miniunit_tests\miniunit_tests.exe -- make -hide-all-packages -no-user-package-conf -i -idist\build\miniunit_tests\min iunit_tests-tmp -i. -idist\build\autogen -Idist\build\autogen -Idist\build\miniu nit_tests\miniunit_tests-tmp -optP-DNEW_EXCEPTION -optP-include -optPdist\build\ autogen\cabal_macros.h -odir dist\build\miniunit_tests\miniunit_tests-tmp -hidir dist\build\miniunit_tests\miniunit_tests-tmp -stubdir dist\build\miniunit_tests \miniunit_tests-tmp -package QuickCheck-1.2.0.0 -package Takusen-0.8.4 -package base-4.0.0.0 -package mtl-1.1.0.2 -package old-time-1.0.0.1 -package time-1.1.2. 2 -O -XCPP .\Test/MiniUnit/Main.hs I don't see ghc flag -main-is in here. What do I need to do to get it to build the executable? Also, is there a way to get it to just build miniunit_tests.exe i.e. without rebuilding the library and another executable target? Alistair

2 2

[Hackage] #468: resolve version conflicts that are resolvable
by Hackage 20 Jan '09

20 Jan '09

#468: resolve version conflicts that are resolvable --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- http://www.haskell.org/pipermail/haskell-cafe/2009-January/053247.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/468> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #469: Support relocatable packages
by Hackage 20 Jan '09

20 Jan '09

#469: Support relocatable packages ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very hard (<1 week) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- This is both useful and doable on both Windows and Unix systems. We already have limited support for relocatable (also sometimes called prefix-independent) packages on Windows. Specifically, a relocatable package is often what people want when they want to prepare a package for redistribution, especially on Windows for use with an installer. What is required is that an exe and all supporting files (data files and potentially also other shared libs) exist together in one directory hierarchy and that that directory can be placed anywhere in the filesystem and the exe will still be able to find all its associated support files. There are some restrictions on preparing a relocatable package. In particular the user must configure it such that all install directories for the various kinds of files (libdir, datadir etc) are relative to the `$prefix`. Configuring a relocatable package should be something that is done explicitly. At the moment it is done simply by configuring it in the right way, but Cabal is never aware that the user is trying to construct a relocatable package. If it is explicit then we can take different actions if necessary (as it is on unix) and do additional checks. So a configure option `--relocatable` or something should be used. Installing a relocatable package is somewhat of an exception because it involves using a prefix which would otherwise be empty. Creating an image for a relocatable package would use a empty `$prefix`. The tricky issues that have to be addressed are: * data files for the program itself * data files in library dependencies * shared libraries The mechanism for finding data files at runtime is the `Paths_pkgname` module that Cabal generates. On Windows this can make use of the Win32 api that lets a .exe program discover where it was run from. On unix there is no reliable equivalent but the next best alternative is to use wrapper scripts to set environment variables before running the real program. This mechanism can work pretty well for data files that belong to the executable. It is rather harder for data files in dependent packages (see #466). One option would be to copy the data files belonging to dependent packages and install them along with the executable (checking for clashes). This would involve being able to locate the data files of installed libraries which would require extending the data stored for installed packages. Libraries that require data files are relatively rare (though this should be checked) so this feature could be punted for an initial version. In future there will also be the issue of shared libraries to consider. That is, when Haskell implementations can produce Haskell libs as shared libraries. This complicates the construction of relocatable packages. Again the approach taken on Windows and Unix will have to be different. On Windows it will be possible to copy the .dll files into the same directory as the .exe file (or a subdir if using .manifest files). On Unix a wrapper script using `LD_LIBRARY_PATH` will probably be necessary. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/469> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #306: can't figure out how to use data-files
by Hackage 20 Jan '09

20 Jan '09

#306: can't figure out how to use data-files ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.9 Platform: | ----------------------------+----------------------------------------------- looking into the docs, `data-files` seem easy. but when i try this: {{{ -- p.cabal name: p version: 0 license: BSD3 build-depends: base build-type: Simple exposed-modules: P data-files: file }}} {{{ -- Setup.hs import Distribution.Simple main = defaultMain }}} {{{ -- P.hs module P(file) where import Paths_p file = getDataFileName "file" }}} {{{ -- file data here }}} installation succeeds, but usage doesn't: {{{ $ runhaskell Setup.hs --version Cabal library version 1.5.1 $ runhaskell Setup.hs configure --prefix=c:/ghc/libraries --datadir='$prefix' Configuring p-0... $ runhaskell Setup.hs build -v Creating dist\build (and its parents) Creating dist\build\autogen (and its parents) Preprocessing library p-0... Building p-0... Building library... Creating dist\build (and its parents) c:\ghc\ghc-6.9.20080514\bin\ghc.exe -package-name p-0 --make -hide-all- packages -i -idist\build -i. -idist\build\autogen -Idist\build -odir dist\build -hidir dist\build -stubdir dist\build -package ba se-3.0 -O P [1 of 2] Compiling Paths_p ( dist\build\autogen\Paths_p.hs, dist\build\Paths_p.o ) [2 of 2] Compiling P ( P.hs, dist\build\P.o ) Linking... c:\ghc\ghc-6.9.20080514\bin\ar.exe q dist\build\libHSp-0.a dist\build\P.o c:\ghc\ghc-6.9.20080514\bin\ar.exe: creating dist\build\libHSp-0.a c:\ghc\ghc-6.9.20080514\gcc-lib\ld.exe -x -r -o dist\build\HSp-0.o.tmp dist\build\P.o $ runhaskell Setup.hs install Installing: c:/ghc/libraries\p-0\ghc-6.9.20080514 Registering p-0... Reading package info from "dist\\installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. }}} {{{ $ ghcii.sh GHCi, version 6.9.20080514: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :browse P file :: IO FilePath Prelude> P.file Loading package p-0 ... linking ... <interactive>: c:/ghc/libraries\p-0\ghc-6.9.20080514\HSp-0.o: unknown symbol `___stginit_pzm0_Pathszup_' ghc.exe: unable to load package `p-0' Prelude> :set -package p package flags have changed, ressetting and loading new packages... Loading package p-0 ... linking ... ghc.exe: c:/ghc/libraries\p-0\ghc-6.9.20080514\HSp-0.o: unknown symbol `___stginit_pzm0_Pathszup_' ghc.exe: unable to load package `p-0' > }}} what am i doing wrong? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/306> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

Participation in Cabal / Hackage development
by Duncan Coutts 20 Jan '09

20 Jan '09

All, I just mentioned ideas for Cabal 2 but I should also like to talk about how we can go about increasing participation in the development effort. We currently have nearly 200 open tickets which include many important bugs and no shortage of good ideas for useful new features. Our limiting factor is developer time. Most of us use the Cabal / Hackage system in one way or another. Most of us are familiar with its annoyances and limitations. Unfortunately the number of people helping out has dropped rather in the past year or so. Perhaps we should run a little poll like the darcs hackers did to find out what we could do to increase participation so we can get on with building the tools that we all want, but a bit more quickly. Duncan

2 3

[Hackage] #310: Install with multiple compilers
by Hackage 20 Jan '09

20 Jan '09

#310: Install with multiple compilers ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- It would be nice to be able to install a package with multiple compilers in one pass. For example, with the current Setup.[l]hs interface, {{{runhaskell Setup.hs configure --ghc --hugs --jhc}}} should configure for all three compilers, and then the build and install steps should perform the steps for all three as well. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/310> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Haskell-cafe] Cabal dependencies
by Duncan Coutts 20 Jan '09

20 Jan '09

On Thu, 2009-01-15 at 18:38 -0500, Stephen Hicks wrote: > Hi, > > I'm having some difficulty specifying dependencies in my .cabal file > for a package I'm looking to upload to hackage soon. The difficulty > is as follows. I basically want to specify > parsec (>= 2.1 && < 3.0.0) || (> 3.0.0 && < 4) When we first introduced this kind of version range syntax we were unsure if it was too general or not. We want to be able to translate into other systems and they're typically more restrictive. Internally we can easily represent the above expression as it uses arbitrary unions and intersections. However the external parser still only allows two clauses (I think it's two). Personally I'm all for lifting that restriction. Yes it makes it a bit harder for translating into some systems but I don't see that as a real issue. If the package really does require the more complex version range then forcing the package author to lie by using a less expressive syntax does not help. We can still make the same choice at the point when we translate into native packages. Also, as it happens there is a way of getting around the restriction anyway, which makes the restriction effectively pointless. That is by listing the same dependency more than once. All the version constraints must be satisfied so you can write: build-depends: parsec >= 2.1 && < 4, parsec < 3.0.0 || > 3.0.0 (have I got that right?) So I'd be interested to get feedback on lifting the restriction and the impact that might have on translation into native packages. > The problem is that 3.0.0 as it exists on hackage is missing a > constructor that I need (namely, Postfix, in the compatibility > module). The bug was fixed and will presumably work fine if a newer > version of parsec is ever uploaded to hackage, and my package works > fine with older parsecs as well - I just want to exclude this one > version. How can I go about doing that? Try the above. > A secondary question is this - I can actually compile with version > 3.0.0 by just not using this constructor, although it does reduce the > package's functionality. I've seen flags in various .cabal files, and > presumably I could invent a flag to make it work with 3.0.0, but I'm > confused about how these flags are set. Yes, if you need compatibility with older versions of Cabal then you'd need to use a flag. If you're prepared to require Cabal-1.6 or later then you can use the cpp macro: #if MIN_VERSION_parsec(3,0,0) though of course that only gives you >= 3.0.0, you'd need more tricky combinations to get == 3.0.0, perhaps by assuming >= 3.0.1 is ok. For older Cabal versions the main option is a flag, like so: flag parsec3 ... if flag(parsec3) build-depends: parsec == 3.0.0 cpp-options: -DUSING_BAD_PARSEC else build-depends: parsec > 3.0.0 || < 3.0.0 > Specifically, cabal-install has never asked me anything about flags, > so what's the point? Or does it automatically set whichever flags > satisfy the dependencies? It tries to work out what flags to set automatically (based on the platform, the available packages and flag defaults in each package). You can override them from the command line if you want to or need to. Duncan

1 0