January 2010 - cabal-devel

[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

[Hackage] #622: wrong HTTP Content-Type for tar.gz files, breaking cabal-install behind some proxies.
by Hackage 03 Jan '10

03 Jan '10

#622: wrong HTTP Content-Type for tar.gz files, breaking cabal-install behind some proxies. --------------------------------+------------------------------------------- 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: | --------------------------------+------------------------------------------- As can be seen here, {{{ > HEAD http://hackage.haskell.org/packages/00-index.tar.gz ... Content-Encoding: x-gzip Content-Length: 1398234 Content-Type: application/x-tar ... }}} the file is declared as a tar file with a {{{gzip}}} content encoding. This breaks with at least on virus scanning proxy, namely !AvkHttp (of !InternetSecurity by G DATA): {{{ > cabal update -v3 Downloading the latest package list from hackage.haskell.org Sending: GET /packages/archive/00-index.tar.gz HTTP/1.1 Host: hackage.haskell.org User-Agent: cabal-install/0.8.0 Creating new connection to hackage.haskell.org Received: HTTP/1.1 200 OK AvkHttp: timeout-protection ... AvkHttp: timeout-protection Date: Sun, 03 Jan 2010 09:52:53 GMT Server: Apache/2.2.3 (Debian) Last-Modified: Sun, 03 Jan 2010 09:38:56 GMT ETag: "388d94-1555da-5fa0cc00" Accept-Ranges: bytes Content-Length: 17571840 Content-Type: application/x-tar Downloaded to /home/nils/.cabal/packages/hackage.haskell.org/00-index.tar.gz cabal: Codec.Compression.Zlib: incorrect header check }}} As you can see, the proxy unpacked the data, breaking cabal-install. https://bugs.launchpad.net/malone/+bug/173096 describes a similar problem, and has some discussion about why using {{{Content-Encoding}}} in this way is useful in some cases but hurtful in others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/622> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1