- cabal-devel - Haskell.org

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

[RFC] Don't overwrite an existing Makefile
by Bryan O'Sullivan 30 Apr '07

30 Apr '07

Hi, Simon - Another problem with "Setup makefile" is that it will overwrite an existing Makefile, even if that file perhaps ought to be present. For example, using "Setup makefile" in a Cabal repo clobbers Cabal's own Makefile. The attached patch causes "Setup makefile" to refuse to overwrite an existing file. I'm a bit ambivalent about it, but I don't see another simple, predictable way to avoid the possibility for foot-shooting. <b

3 4

darcs patch: If "Setup configure" can't satisfy deps set buildable=...
by Ian Lynagh 30 Apr '07

30 Apr '07

Wed Apr 25 12:33:09 BST 2007 Ian Lynagh <igloo(a)earth.li> * If "Setup configure" can't satisfy deps set buildable=False rather than failing Before there was an odd inconsistency, where ./configure scripts would (on failure) set buildable=False in <package>.buildinfo and return successfully, but if "Setup configure" itself failed due to missing build-deps then it would just exit unsuccessfully. This patch, based on a suggestion from Claus Reinke, makes "Setup configure" behave like ./configure. writeHookedBuildInfo is a bit of a misnomer for this use, but it'll do what we need.

2 1

darcs patch: Put pre-processed source into the dist/b... (and 2 more)
by Duncan Coutts 25 Apr '07

25 Apr '07

Those patches I was talking about. I'd apreciate a review :-) Actually to test it with c2hs also needs a patch to c2hs that I'll send tomorrow. But it should work for alex & happy etc already. Duncan Sun Apr 22 19:56:31 EST 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Put pre-processed source into the dist/build dir rather than src dirs This is generally just a nicer thing to do, we should probably aim to not write any files into the source tree at all. The main change is in the preprocessModule function. It now takes an extra arg which is the destination directory. For now I'm passing the buildDir, but we could consider putting pre-processed files into a separate fir from where the .o and .hi files end up. To work out the correct destination file we need to know not only the source file but which of the search dirs it was found in, since the relative file name will be the name of the source file relative to the search dir it was found in, not the name relative to the top of the source tree. This is so that we will be able to find the pre-processed .hs file just by adding dist/build to the sources search path when we compile (eg with -i for ghc). This almost certainly breaks the sdist thing where pre-processed files get included into the tarball. So that'll need looking at. Sun Apr 22 20:05:58 EST 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Generalise PreProcessors to take more detailed args Most pre-processors just need the full source file and target file names. More complicated ones where the generated files have to embed links to each other need more information. For example c2hs generates .hs file that reference generated .h files. These links should be relative to the dist/build dir and not to the top of the source tree, since we do not want to add -I. to the includes search path. We only want to use -Idist/build, hence the embeded links must be relative to that. Therefor c2hs needs to know the base output directory as well as the name of the file relative to that. So we add a new type PreProcessorFull that has this extra info and a function simplePP :: :: PreProcessor -> PreProcessorFull for the common case of most existing pre-processors that do not need this extra info. This patch doesn't actually change the c2hs stuff, that comes next. Sun Apr 22 20:26:17 EST 2007 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * call c2hs using the more detailed info we use --output-dir=dist/base and --output=<file relative to the search dir it was found in>.hs This actually depends on a patch in c2hs to make it treat --output-dir in the way we want. That patch will be forthcomming soonish. But the point is: c2hs --output-dir=dist/base --output=Foo/Bar.hs src/Foo/Bar.chs will generate dist/base/Foo/Bar.hs and also dist/base/Foo/Bar.h but inside the .hs file it'll reference Foo/Bar.h so when we compile the .hs file we have to -Idist/base Clear as mud?

2 2

[PATCH] initialBuildSteps shouldn't run a complete build
by Bryan O'Sullivan 24 Apr '07

24 Apr '07

Hi, Simon - The "Setup makefile" refactoring you did was a little over-ambitious, and ended up doing a complete serial build before it generated any Makefile :-) <b

2 3

[Fwd: Bug and Features Cabal]
by Simon Marlow 23 Apr '07

23 Apr '07

Forwarding on behlaf of Hans van Thiel <hthiel.char(a)zonnet.nl>. Hello, I got this email address from the Cabal documentation page, if it should be addressed elsewhere, my apologies and please redirect me, if you can. I'd like to report my experience using Cabal for a simple distribution. 1) building the package according to the instructions worked fine, no error messages. Uploadig to HackageDB resulted in an error that the .cabal file could not be found. The reason was its name, "emping-0.1.cabal", which should have been "Emping-0.1.cabal". Changing fixed it. I did not succeed in installing my own program myself with Cabal, configuration seemed to work fine, but build gave a message that source files could not be found. I have not tried it yet, but maybe the above was the problem. (It's not serious, it's a simple utility with no dependencies and just compiling is sufficient.) 2) the HackageDB test gave warnings that "license-file" and "category" were missing, warnings which did not occur when building. 3) it is not clear from the Cabal documentation whether the fields in the .cabal file are case sensitive or not. As a feature, I feel that there should be fields for included user documentation files or directories in the .cabal file. (I even feel they should be obligatory for all packages.) The Cabal documentation mentions possible name clashes for packages as a concern. I tried the Eclipse solution for this, naming the package with my URL in reverse i.e. "nl.speedlinq.j-van-thiel.emping" but this resulted in a "parse error". I don't know, but the convention seems to work well for the Eclipse people. Another possibility might be the use of a doi (digital object identifier) in the package name? The only problem is you'd need to get a domain prefix from the current administration agency, but a doi as unique identifier would also solve clashes. Finally, I think Cabal is a great idea and a great help. I hope you will keep on developing and improving it. Best Regards, Hans van Thiel

3 2

Re: cabal ignores ld-options?
by Duncan Coutts 23 Apr '07

23 Apr '07

On Mon, 2007-04-23 at 06:20 +0100, Frederik Eaton wrote: > > Frederik, in case it's not clear, the reason you're running into > > problems is because you're doing things people haven't done much before > > with cabal, that is try and use it as part of a larger multi-language > > project. I'm not at all saying that's a bad thing, it's just that's why > > you're noticing these missing features. > > OK, well perhaps a warning in the Cabal documentation is in order: > "Don't use this system if you need flexibility." Sure, an explicit statement of coverage, what it does and doesn't handle yet etc would be a very good thing. > > Right, since you're making a library ld is never called (it's ar that is > > used to make an .a archive file). > > That is not true, both ld and ar are called. See the file named > cabal.out which I attached to my previous message. Ah yes I see, but that still would not do what you want. The ar call is to make the ordinary static lib. The ld call is to make the GHCi .o equivalent. So if you added a .o file to the ld arguments there but not for ar then your thing only work with GHCi and not in the normal static linking case. > When ld is called, then object files for compiled C files are included > on the command line (gslaux.o), so I would expect object files for > compiled C++ files to belong here as well. Right. As I said we do have a mechanism in Cabal to compile C files and include them in a package. I was suggesting and asking for feedback on a similar mechanism to allow arbitrary .o files to be included too. > If the Cabal documentation were correct, then I think ld-options would > be what I want. As I say, it would not be what you want. You need to be able to specify a bunch of other object files to link in, like we have the c-sources: field. You'd want other-object-files: or something along those lines. > > Perhaps there should be a mechanism to include arbitrary extra .o files > > into the archive that cabal produces, but remember that this would be > > totally ghc-specific. No other Haskell implementations use archives or > > can necessarily link arbitrary .o files. > > I see, so FFI in other implementations relies on dynamic or static > libraries? I think so but I'm not 100% sure. > Perhaps I should avoid using Cabal, since it has caused so much > inefficiency. I will go through cabal.out and put those commands in a > makefile. It doesn't scale to have cabal try and build sources from lots of other languages. C is a special case. If you're doing a multi-language project you need something else at the top level of your build system. You can use cabal to build the Haskell part and whatever else to build the other language stuff. Each can produce their .a / .so files which you install together or link together. Duncan

1 0