May 2007 - cabal-devel

Stack overflow on hackage upload
by Bjorn Bringert 11 May '07

11 May '07

I can't seem to upload the new GD release to hackage: $ cabal-upload dist/gd-3000.1.0.tar.gz Uploading dist/gd-3000.1.0.tar.gz... ERROR: 500 Internal Server Error <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" ><head ><title >500 Internal Server Error</title ></head ><body ><h1 >500 Internal Server Error</h1 ><p >stack overflow</p ><hr /><address >Haskell CGI on Apache/2.0.54 (Debian GNU/Linux) at hackage.haskell.org, port 80</address ></body ></html > I get the same error when using my web browser to upload. I have attached the tarball I tried to upload. /Björn

3 6

Re: Integrating Cabal, Haddock, HsColour
by Simon Marlow 06 May '07

06 May '07

Roberto Zunino wrote: > I've just extended Cabal so to generate docs with links to highlighted > sources. Now > > ./Setup configure > ./Setup haddock --link-to-hscolour > ./Setup hscolour --css my_own_stylesheet.css > > generates HTML as this one: (run on Cabal itself) > > http://www.di.unipi.it/~zunino/tmp/dist/doc/html/Cabal/Distribution-Program… > > Click on the "Source" links on the right. You will be sent to the exact > line. The whole Cabal docs+sources are online. Colours have been chosen > to match my emacs configuration :-P . > > This relies on a couple of minor tweaks to Haddock and HsColour which I > darcs-sent this morning to the authors. > > Comments are welcome. > > - Is this worth including in the next Cabal version? Looks really nice! (BTW, cabal-devel(a)haskell.org is a better place to discuss Cabal improvements). I'm happy for it to go in. > - Are the options above good choices? I'd make 'Setup haddock --hscolour' do both steps. > - Is the directory tree OK? Currently Haddock creates (under dist/doc/html) Looks fine. Cheers, Simon

4 4

cabal "fails" with no explanation
by Stefan O'Rear 04 May '07

04 May '07

stefan@stefans:/usr/local/src/xmonad$ runhaskell Setup.lhs clean -v5 cleaning... stefan@stefans:/usr/local/src/xmonad$ echo $? 1 stefan@stefans:/usr/local/src/xmonad$ ghc -V The Glorious Glasgow Haskell Compilation System, version 6.7.20070502 stefan@stefans:/usr/local/src/xmonad$ configure, build, and install all also work but return 1. The same issue is observed with X11-extras. Stefan

3 3

cabal-upload & cabal-install
by Duncan Coutts 04 May '07

04 May '07

Hia Ross, Bjorn, Pepe Iborra and I were hacking on cabal-install today. I hope you like our patches :-). Pepe updated it to use filepath so it'd work on windows and I fiddled with locations of config and things to try and make installation simpler so it'll work "out of the box". I was also trying cabal-upload. I found that cabal-upload needs some functions from the HTTP lib that are not actually exported. In particular the stuff to do with authorisation in the Browser module. It looks like it ought to be exported since it isn't actually used internally. When I do patch the HTTP lib to export that, cabal-upload works for me. I uploaded filepath-1.0 today using it. However I failed to upload Cabal-1.1.6.2 which I also released today. Via both the website and cabal-upload interfaces it failed the upload after a few 100k, so I think it's a server side issue. Does it have a limit on the upload size? cabal-1.1.6.2.tar.gz is just over 500k. You can grab it here and try: http://haskell.org/cabal/release/latest/cabal-1.1.6.2.tar.gz My general impression is that cabal-install, hackage and cabal-upload are really nice, especially the hackage web ui. You've done a lot of work! What do we need to do next? Should we invite a little bit of wider testing on cabal-install + hackage and get some user feedback. If that's good we should actively advertise and push it. One longer term thing I was thinking about was using hackage and cabal-install to gather testing feedback. We could have cabal-install report (with user consent) build successes and failures, including useful info about the environment, including the platform, Haskell implementation and version, the version of cabal, cabal-install and versions of the all the dependent packages (not sure if it should be directly or transitively). This would be a great way to do distributed testing and a way of finding out which packages are well used and tested. If summary info is on the website it also allows users to find out if a package is likely to work on their machine. Duncan

3 4

Detrimental c2hs / "other-modules" interaction
by mstone＠sccs.swarthmore.edu 04 May '07

04 May '07

Dear Cabal Developers, First, thanks for the excellent work so far. Second, I thought I'd report a frustrating experience I had on my first attempt to package a library. I'm currently extracting a Cairo binding from Gtk2hs because I want to use Cairo on a server that doesn't have X or GTK readily available. As I went about adapting Gtk2hs' binding, I ran into the following issue: 1) Cabal does not clean up after c2hs - in particular, it does not delete the temporary .chi and .chs.h files that c2hs produces for each file it processes. 2) Cabal does not do dependence analysis. Consequently, the "other-modules" field of my cairo.cabal is order-sensitive. Together, these mean that after I manually delete those temporary files, my build fails mysteriously because the dependencies are not being resolved in an order that c2hs can work with. This in turn makes it non-trivial to make reliable builds. Please let me know if you'd like any further information. Thanks, Michael Stone

2 1

Re: hackageDB directory layout
by Bjorn Bringert 03 May '07

03 May '07

On May 3, 2007, at 10:24 , Ross Paterson wrote: > [for some reason I don't seem to be able to get this to the > libraries list, so I'm sending it to cabal-devel] > > I propose to change the directory layout of the HackageDB data, by > putting > each version in a separate directory (to simplify future expansion). > This will not affect users of the web interface, but will be a > breaking > change for those who reference the files directly, notably cabal- > install. > > Here's how the positions of the files of the binary package would > change > (-> denotes a symbolic link): > > Current layout Proposed layout > -------------------------------------------------------------------- > binary/binary-0.2.cabal binary/0.2/binary.cabal > binary/binary-0.2.tar.gz binary/0.2/binary-0.2.tar.gz > binary/binary-0.2.misc/doc/html/ binary/0.2/doc/html/ > binary/binary-0.3.cabal binary/0.3/binary.cabal > binary/binary-0.3.tar.gz binary/0.3/binary-0.3.tar.gz > binary/binary-0.3.misc/doc/html/ binary/0.3/doc/html/ > binary/latest.misc -> binary-0.3.misc binary/latest -> 0.3 Fine by me. In cabal-install you probably only need to change Network.Hackage.CabalInstall.Update.pkgURL. /Björn

1 0

Cleaning up hooks
by Simon Marlow 03 May '07

03 May '07

I think the API for hooks is in need of an overhaul. It has a few problems: 1. it isn't extensible. When a new command is added, typically all the Setup.hs scripts break because they haven't hooked then new command. 2. it isn't composable. It ought to be easy to augment PackageDescription in Setup.hs, but it isn't: to do it right, you have to modify every hook. 3. It's too complicated. I'm sure we don't need all those pre- and post- hooks. 4. tools that build on Cabal (e.g. cabal-rpm) don't work with hooks. If your Setup.hs uses hooks to modify the PackageDescrption, then cabal-rpm won't see the modifications. I can fix 1-3, but 4 is more of a design problem. I'll outline a possible partial solution to 4 later, however. Anyway, here's the basic idea. A common thing to want to do in Setup.lhs is to modify the PackageDescription, so we provide a way to do that: modifyPackageDescription :: (PackageDescription -> IO PackageDescription) -> UserHooks -> UserHooks modifyPackageDescriptionPostConf :: (PackageDescription -> LocalBuildInfo -> IO PackageDescription) -> UserHooks -> UserHooks modifyPackageDescription supplies a function that is run before every command, to modify the existing PackageDescription, and it can do IO. modifyPackageDescriptionPostConf is similar, except that it does not apply to the configure command, and it gets to see the LocalBUildInfo. These mostly subsume all the preHooks. For example, modifyPackageDescriptionPostConf can be used to read the results of the autoconf script. (We'll also need to provide a way to merge a new BuildInfo with the existing PackageDescription). The good thing about this is it's extensible and composable. Adding more commands to Cabal won't break Setup.lhs scripts that use these combinators. This could also help us solve problem (4) above: Cabal can provide a way to output the modified PackageDescription to a file, that can be read in by cabal-rpm. For example, "cabal-setup descr" could output the real PackageDescription. We might still want to hook the real commands, however. So let's look at simplifying the UserHooks type: type ConfHook = Args -> ConfigFlags -> PackageDescription -> IO LocalBuildInfo type Hook a = Args -> a -> PackageDescription -> LocalBuildInfo -> IO () data Hooks = Hooks { confHook :: ConfHook, postConfHook :: Hook ConfigFlags buildHook :: Hook BuildFlags, makefileHook :: Hook MakefileFlags, cleanHook :: Hook CleanFlags, copyHook :: Hook CopyFlags, installHook :: Hook InstallFlags, sdistHook :: Hook SDistFlags, registerHook :: Hook RegisterFlags, unregisterHook :: Hook UnregisterFlags, haddockHook :: Hook HaddockFlags, pfeHook :: Hook PfeFlags } I've missed out runTests and a few others, but the main idea is that I got rid of most the pre- and post-hooks. The configure command is special, because it doesn't see the LocalBuildInfo, so we also need a postConfHook for doing further actions after configure (e.g. running the autoconf script). Suppose we supply thenHook: thenHook :: Hook a -> Hook a -> Hook a thenHook hook1 hook2 args flags pd lbi = do hook1 args flags pd lbi hook2 args flags pd lbi Then to add a post-hook to the build command you could do this: addPostBuild :: Hook BuildFlags -> Hooks -> Hooks addPostBuild hook hooks = hooks { buildHook = buildHook hooks `thenHook` hook } Alternatively, we could supply addPostBuild, addPreBuild, etc. and hide the representation of the Hooks type completely. Comments? Cheers, Simon

2 3

Re: [Haskell-cafe] Cabal, lib and exe in one
by Duncan Coutts 02 May '07

02 May '07

On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: > >So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you > >just need: > > > >hs-source-dirs: test-src, src > > No, that's not enough, I also have to add the following lines to make > the executable compile and link: > > extensions: ForeignFunctionInterface > c-sources: csrc/ptrace.c > > That is, I end up compiling the library a second time! Can't I get the > executable to link against the library that was just created? > I was just expecting to not have to repeat myself in the cabal file. > Not such a strange thing to expect from a build system, I think :-) Yes this is an interesting question about what it means to have programs in the same cabal package as an executable. Currently having a executable and a library inside a cabal package is not the same thing as having a library package and separate package that contains only that executable. The difference is that when the executable is in the same cabal package it merely has access to the same modules, it doesn't 'depend' on that library package exactly. So for example it can access modules which are not exposed by the library and indeed it can compile those same modules with completely different build flags. So currently those modules will be built twice. It's not clear to me that this is the right meaning, or indeed that we should allow multiple entries in a single .cabal file. I think it might be better to just have multiple .cabal files (possibly in the same directory). Then we could be explicit and state that an executable depends on the library or if we want to use different build flags, or use modules that are not exposed by the lib then we can do that and only in that case do we build those modules twice. > Also, I don't really see what you mean by "that dir can be placed > anywhere by the user". That dir is created as part of the build > process and it's location is, AFAICS, always going to be ./dist/build. Actually it's location can be set at configure time with --scratchdir= so that for example you could put it in a temp dir or something. Duncan

2 1

RE: darcs patch: added cppOptions and c2hsOptions
by Vivian McPhail 02 May '07

02 May '07

Hi Duncan, I added cppOptions because in the Cabal.cabal file there was a comment to add cppOptions and so I did it. With respect to c2hsOptions, the problem is that c2hs passes options to the CPP nonstandardly (with --cppopts=), so even if I have an -I* option in my ccOptions that gets passed to c2hs, this works for c2hs, but doesn't get passed to the cpp that c2hs uses. I've sent a message to the c2hs/cabal mailing list with a dummy package that recreates all the problems I had on mingw/WinXP. The reason the c files are outside the Cabal hierarchy is that they are supposed to mimic libs/headers that are already on the system and would (normally) be found with an autoconf script. I think it would be a great idea to change the name of the .h file that c2hs generates. It would make naming Haskell sources/modules more consistent with their targets. Cheers, Vivian > -----Original Message----- > From: Duncan Coutts [mailto:duncan.coutts@worc.ox.ac.uk] > Sent: Wednesday, 18 April 2007 3:31 p.m. > To: Vivian McPhail > Cc: cabal-devel(a)haskell.org > Subject: Re: darcs patch: added cppOptions and c2hsOptions > > On Wed, 2007-04-04 at 03:33 +1200, Vivian McPhail wrote: > > > Wed Apr 4 03:32:49 New Zealand Standard Time 2007 Vivian McPhail > > <omconsult(a)gmail.com> > > * added cppOptions and c2hsOptions > > Hia Vivian, > > Can you explain to me again exactly why we need these extra options? > As I see it, cpp options can just be included in the cc options, is > there any need to separate them? > > Cabal currently looks for -D* -U* and -I* flags in the cc options and > passes them to c2hs. Are there any other ones that we are missing > there? > It's quite convenient for users not to have to separate the cc flags > into cpp ones, since many other tools intermingle them (off the top of > my head I can think of pkg-config). > > As for the c2hs options, again I'm not clear as to why this is > necessary. c2hs doesn't support that many interesting flags: > > -C CPPOPTS --cppopts=CPPOPTS pass CPPOPTS to the C preprocessor > -c CPP --cpp=CPP use executable CPP to > invoke C preprocessor > -d TYPE --dump=TYPE dump internal information > (for debugging) > -h, -? --help brief help (the present message) > -i INCLUDE --include=INCLUDE include paths for .chi files > -k --keep keep pre-processed C header > -l --copy-library copy `C2HS' library module in > -o FILE --output=FILE output result to FILE > (should end in .hs) > -p PLATFORM --platform=PLATFORM platform to use for cross > compilation > -t PATH --output-dir=PATH place generated files in PATH > -v --version show version information > > I think all of these are either not useful or can be selected > automatically. > > As for the optional .h file that can be passed on the command line, > the better way to do that is to put the #include inside the .chs file. > > The alternative is to extend c2hs to accept many .h files on the > command line and we can pass all the files in the 'includes:' field to > c2hs. I'm considering extending c2hs to allow this. I'm also planning > to change c2hs so that the .h file it generates will not clash with > anything else, for foo.chs it'll generate foo.chs.h and possibly > foo.chs.c too. > > Is there anything I've missed? > > Duncan >

3 9