- cabal-devel - Haskell.org

Meaning of version tags in cabal files
by C Rodrigues 18 Jan '10

18 Jan '10

I noticed that cabal will parse, but ignore, version tags. For example, the two lines appear to be equivalent in how a package gets built: Version: 1.1Version: 1.1-alternate Arguably this is not the right thing to do, as it changes the semantics of versions. For example, I can install version 1.1 of a package without replacing version 1.0, but if I try to install version 1.0-alternate, I will actually replace version 1.0. I'm not against discarding version tags, but I'd like to know if there's a rationale for _silently_ discarding them. -heatsink _________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. http://clk.atdmt.com/GBL/go/196390706/direct/01/

3 2

build-dep command
by Ian Lynagh 17 Jan '10

17 Jan '10

Hi all, This patch adds a build-dep command to cabal-install, so cabal-install build-dep mypackage installs all the dependencies of mypackage, but not mypackage itself. There are at least a couple of problems with this patch: * I don't know what happens if you say cabal-install build-dep foo bar and bar is one of the transitive dependencies of foo. * Removing the packages from the install plan should probably do so directly, rather than converting the plan to a list and back again. But I'm sending it now so it doesn't just sit on my HD for eternity. Thanks Ian

1 0

[Hackage] #462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds.
by Hackage 16 Jan '10

16 Jan '10

#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | --------------------------------+------------------------------------------- Given these packages: C depends on B, B depends on A. A failed to build, B and C were uploaded later and failed also. Later, A was fixed, bumped version, re-uploaded. B did not need fixing, so remained untouched. C was also fixed, bumped version, re-uploaded. Finally, A rebuilt OK, B was not scheduled for rebuilding, C failed because B was still failed. It is requested that once a package that failed to build is updated and builds, all packages immediately dependent upon it are scheduled for rebuild. Then the same logic applies to those that rebuilt OK (their dependencies are scheduled for rebuild). Thanks. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/462> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #598: Bogus build failures on HackageDB
by Hackage 16 Jan '10

16 Jan '10

#598: Bogus build failures on HackageDB --------------------------------+------------------------------------------- Reporter: mboes | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- HackageDB reports build failures for packages due to inconsistent dependencies. For instance, the dedukti package currently has a build failure because it depends on both bytestring and text. The latest version of bytestring is 0.9.1.5, but text is built using bytestring-0.9.1.4. This causes a build failure because the functions in text expect as arguments something of type ByteString from bytestring-0.9.1.4, not something of type ByteString from package bytestring-0,9.1.5. If the text package were built using the latest available version of bytestring, as would happen after a "cabal install text" on a fresh system, the problem would go away. Always building packages with the latest versions of their dependencies available isn't a solution, because dedukti could, for instance, depend on some specific version of bytestring yet text might happen to be built with another version on the Hackage server. Could there be a way to at least detect when build failures are due to inconsistent versions in dependencies, which is a problem specific to the Hackage server installation and not the package itself? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/598> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ?
by Hackage 14 Jan '10

14 Jan '10

#207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: misc | Version: HEAD Severity: normal | Keywords: tags source tagfile Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------+------------------------------------------------- == Introduction == I personally depend on tags because the source code only tells what is really going on. So it would be incredible useful to not only get information using ghci after loading libs but also beeing able to jump to all functions you might be using anywhere (The only solution providing this in all cases is uning tags, right? Because cpp defines can introduce new functions.. To be able to jump to the code source must be installed along with libs (the way you can optionally install haddock docs) == Use case: == setup configure --with-tags --install-source (or something like that) setup build && setup install do this for each dependency given in the .cabal file (VIM:) let tags+=system('ghc-pkg --query-tagfile-location haskell98-1.0.0.0') == Issues: == * Which tool to generate tag files? * ghc(i) when targeting ghc * the hasktags program shipping with ghc * some others? * Tagfile path type relative or absolute? * absolute: After moving/ installing the sources the tagfile must be patched * relative: Do editors take the right base directory to find source files? * When to invoke the tagfile generating program? * Perfect case would be after all preprocessing has been done (Thus the tagging program should understand line number changing comments!) * Template Haskell? ( This is really tricky I think ) * Hmm sorted tagfiles would be useful as well :) == alternatives ? == If you do not think this is useful (mandatory?) how do you lookup code? (Yes I know hoogle :) perhaps using Eclipse or Visual Studio? I'd like to start implementing this somehow the next weeks. So don't hesitate and start discussing Marc Weber -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/207> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 5

patch applied (cabal-install): Don't generate #! lines in Setup.hs files in cabal init
by Duncan Coutts 14 Jan '10

14 Jan '10

Wed Jan 13 19:35:01 PST 2010 Duncan Coutts <duncan(a)haskell.org> * Don't generate #! lines in Setup.hs files in cabal init We don't want to encourage multiple ways of invoking Setup The one true (cross-platform) way is: runghc Setup M ./Distribution/Client/Init.hs -2 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20100114033501-adfee-…

1 0

patch applied (cabal-install): Fix the display of the license in "cabal list" output
by Duncan Coutts 13 Jan '10

13 Jan '10

Wed Jan 13 11:19:13 PST 2010 Duncan Coutts <duncan(a)haskell.org> * Fix the display of the license in "cabal list" output M ./Distribution/Client/List.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20100113191913-adfee-…

1 0

infelicitous (incorrect?) ordering of flags passed to GHC
by Brent Yorgey 12 Jan '10

12 Jan '10

Hi all, In trying to update xmonad to build without warnings under GHC 6.12.1, I spent a while struggling to turn off some particular warnings with apparently no effect. Eventually I boiled it down to the following, which seems like a problem---or at least, an infelicity---with Cabal. Suppose we have the following Foo.hs file: module Foo where x :: IO Int x = return 5 f :: IO Int f = do x return 3 This compiles fine with no warnings by default; under ghc -Wall it compiles but generates a warning that 'x' returns an Int which is not bound in f's do-block. This is as it should be. Now consider the following .cabal file (the important bits are at the end): Name: cabal-flags Version: 0.1 License: BSD3 License-file: LICENSE Stability: Experimental Category: Development Build-type: Simple Cabal-version: >=1.2 Library Exposed-modules: Foo build-depends: base >= 4 ghc-options: -Wall if impl(ghc >= 6.12.1) ghc-options: -fno-warn-unused-do-bind According to http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.h… (see the subsection "Meaning of field values when using conditionals"), inner items (in this case the -fno-warn-unused-do-bind) are appended to outer items (here, -Wall) so I would expect the arguments -Wall -fno-warn-unused-do-bind to be passed to ghc-6.12.1. However, let's see what happens: [byorgey@LVN513-12:~/tmp/cabal-flags]$ cabal clean && cabal configure && cabal build -v2 cleaning... Resolving dependencies... Configuring cabal-flags-0.1... Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing library cabal-flags-0.1... Building cabal-flags-0.1... Building library... Creating dist/build (and its parents) *** /home1/b/byorgey/local/bin/ghc --make -package-name cabal-flags-0.1 -hide-all-packages -fbuilding-cabal-package -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-b340bbd470b5859bcbb920aea62a12cf -O -fno-warn-unused-do-bind -Wall Foo [1 of 1] Compiling Foo ( Foo.hs, dist/build/Foo.o ) Foo.hs:7:7: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- x", or by using the flag -fno-warn-unused-do-bind Linking... /usr/bin/ar -r dist/build/libHScabal-flags-0.1.a dist/build/Foo.o /usr/bin/ar: creating dist/build/libHScabal-flags-0.1.a /usr/bin/ld -x -r -o dist/build/HScabal-flags-0.1.o dist/build/Foo.o /home1/b/byorgey/local/bin/ghc --abi-hash -package-name cabal-flags-0.1 -hide-all-packages -fbuilding-cabal-package -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id base-4.2.0.0-b340bbd470b5859bcbb920aea62a12cf -O -fno-warn-unused-do-bind -Wall Foo Registering cabal-flags-0.1... /home1/b/byorgey/local/bin/ghc-pkg update - --package-conf=dist/package.conf.inplace As you can see in the line marked ***, the flags are passed in the order -fno-warn-unused-do-bind -Wall. The problem is that GHC interprets these flags in left-right order, so if -Wall comes second the -fno-warn-unused-do-bind has no effect; and indeed, the warning in question is generated as you can see. Any ideas? Why does this happen? How hard would it be to fix? And are there any workarounds in the meantime? Also, I'm happy to file a ticket on the bug tracker for this. -Brent

2 3

Cabalising creation of OS X application bundles for GUIs
by Andy Gimblett 11 Jan '10

11 Jan '10

Hi there, I've recently been doing some work on packaging GUIs for OS X, and I'm writing to ask: a) for assurance that the approach taken is sensible and consonant with the Tao of Cabal's, and b) a (probably simple) question about making this work nicely cross- platform, c) for any advice anyone wants to give. :-) Here's the background: For a GUI to run nicely under OS X, it needs to be packaged into an application bundle, which is a folder containing the executable binary and any related resources (such as libraries, icons, etc.) in a designated structure, and marked as an app bundle via a tool called Rez. Without being in such a bundle, the executable runs without its icon, and doesn't respond to user actions. Historically, this has been solved (in a minimal fashion) by a script called macos-app (see http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X) , which is included in the wx distribution. This works, but doesn't integrate very prettily into a cabalised build process. (BTW, are there any gtk2hs/OS X users out there? My (limited) experience suggests that "bare" gtk2hs executables work OK, but don't get focus automatically and of course lack nice icons. Thus, this work could be of use to gtk2hs users as well?) Recently, Eric Kow did some work towards replacing macos-app with equivalent Cabal-based machinery, and I've now polished that up a bit, cabalised it, and made it public on github (http://github.com/gimbo/osxSetup.hs ). I _haven't_ released it on hackage yet, but will do when I'm sure it's going in the right direction. So: - We have a package (cabbage?): cabal-macosx - It exports a single module: Distribution.MacOSX - That exports a post-build hook for creating the app bundle, as well as data types for customisation info (e.g. the icon). and at present that's it. Installation isn't handled yet: "runghc Setup install" just copies the bare executable, which doesn't run properly - so I need to fix that. (Eric's original version did the work upon installation, but I needed it at build-time, so I moved it.) [Another thing I'd like to add: app bundles can carry their own copies of shared libraries, which makes distribution much simpler (you just publish the whole bundle, and it works, standalone). To support this, I'll need to add some a pre-build hook copying them into the right place (and so, building the app bundle will happen even earlier), and also insert some linker flags (Cabal can handle this?).] OK, so that's the picture. Reasonable so far? Now comes the question: Obviously, cabal-macosx is only _really_ a dependency when building on OS X. How can I (indeed, should I?) remove this depedency for other platforms? For example, consider http://github.com/gimbo/osxSetup.hs/blob/master/examples/wxHello/wxHello.ca… - here, I could make cabal-macosx platform-dependent using, say: if os(darwin) Build-Depends: base >= 3 && < 5, cabal-macosx, wx else Build-Depends: base >= 3 && < 5, wx but there is then still an "import Distribution.MacOSX" in Setup.hs (eg http://github.com/gimbo/osxSetup.hs/blob/master/examples/wxHello/Setup.hs) , so build will still fail on other platforms. Is the right way to handle this: a) Just demand cabal-macosx on all platforms, and do the check in Setup.hs (as in the above example)? b) Build platform checks into Setup.hs? I don't even know if that's possible: a platform-specific import? c) Something else? All advice and comments appreciated - thanks for reading this far! Best, -Andy -- Andy Gimblett http://gimbo.org.uk http://www.cs.swan.ac.uk/~csandy/

1 0

bad lines ignored and no warning?
by Marc Weber 04 Jan '10

04 Jan '10

Today I spend quite a while figuring out why I could install base<4 while using flag base4. The reason was that I forgot to add the label build-depends: when patching. If those lines are ignored shouldn't there be a warning? Marc Weber name:QuickCheck version:1.2.0.0 license:BSD3 license-file:LICENSE author:Koen Classen and John Hughes maintainer:libraries@haskell.org category:Testing homepage:http://www.math.chalmers.se/~rjmh/QuickCheck/ synopsis:Automatic testing of Haskell programs description: A library for testing Haskell programs automatically. The programmer provides a specification of the program, in the form of properties which functions should satisfy, and QuickCheck then tests that the properties hold in a large number of randomly generated cases. Specifications are expressed in Haskell, using combinators defined in the QuickCheck library. QuickCheck provides combinators to define properties, observe the distribution of test data, and define test data generators. build-type: Simple cabal-version: >=1.2 flag split-base flag base4 library exposed-modules: Debug.QuickCheck.Batch, Debug.QuickCheck.Poly, Debug.QuickCheck.Utils, Debug.QuickCheck, Test.QuickCheck.Batch, Test.QuickCheck.Poly, Test.QuickCheck.Utils, Test.QuickCheck if flag(split-base) build-depends:base >= 3 && < 5, random if flag(base4) base >= 4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ << cpp-options: -DBASE4 else base < 4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ << else build-depends:base < 3 extensions:CPP

1 0