- Libraries - Haskell.org

cabal experiences
by Ian Lynagh 11 Dec '05

11 Dec '05

Hi all, Here are the issues I ran into while cabalising some stuff recently. It's possible that some of the problems are just me failing to find the right option. * No way to get extra files into the source tarball. * No way to specify extra clean files. * No way to specify extra object files to be put into a library. * With "defaultMainWithHooks defaultUserHooks" clean is not removing config.log, config.status. Hmm, the dist/ directory doesn't seem to be being removed either. * Again with "defaultMainWithHooks defaultUserHooks", sdist doesn't copy configure, * "runghc6 Setup.hs sdist" without configuring tells me to run "setup configure", but wouldn't that restrict me to a particular compiler? (the same applies to clean, although it's not as critical there). * I'm not sure why all cc-options can't be passed to hsc2hs with -C-optc (and likewise ld-options and -L-optl). * I think -threaded should be an extension. Thanks Ian

4 6

RE: Shipments in Cabal
by Simon Marlow 09 Dec '05

09 Dec '05

I just made some changes to my proposal: http://haskell.org/hawiki/Cabal_2fAggregatePackages Mainly I made it so that the sub-packages don't have to be in a subdirectory, this means it will be easier to tar up the aggregate package. On 09 December 2005 14:19, Krasimir Angelov wrote: > For the end user the presence of shipment isn't important. [snip] > The shipment is more important for the developer. yes, exactly what I said! [snip] > I will be lucky with Simon's proposal too. It will allow to build > automatically all packages but I think that it is more complicated. At > least everything that have to be added to Cabal for this proposal will > be required in my proposal too. The aggregate package description is > in fact just a replacement for the shipment description which Isaac > proposed. the point is that an aggregate package is just a package; we don't need a separate concept for it. > I don't think that it is required to have a separate description. The problem with putting all the .cabal files in a single place is that you then have to distribute the whole set of packages together; and it becomes some kind of larger entity for which we need a name ("shipment"). Shipments will be visible at the Hackage level, because Hackage will have to know the set of packages contained in a shipment. I don't think we need to do this. All that is needed is an empty package that depends on all the others. Hackage doesn't need to learn anything new, neither do the other tools. > I have to write an another aggregate package. Will it be distributed > separatelly in Hackage? Yes - but that's exactly how other package systems work. It's flexible and simple. Cheers, Simon

2 1

RE: Shipments in Cabal
by Simon Marlow 09 Dec '05

09 Dec '05

This message got garbled a bit by my mailer. It's easier to read on the wiki: http://haskell.org/hawiki/Cabal_2fAggregatePackages Cheers, Simon On 09 December 2005 11:07, Simon Marlow wrote: > I've read the thread, and I must admit I've been thinking along the > same lines as Duncan. We don't need shipments. The problem is > purely with developing aggregate packages, which we can solve with > either tools or small additions to Cabal. (sorry, I intended this to > be a short message, but it's turned out rather long :-/) > > I don't propose to change much, in fact I want to make the situation > simpler: > > Cabal package > == one library or one executable > == one distro package > == one distributable > > To aggregate packages, just create another package which contains only > dependencies. This is how many distro packaging systems aggregate eg. > all the KDE components into a single KDE package. > > 1. End users: they are served by this just fine. They just > cabal-install > the top-level package, and all the dependencies are magically > downloaded and installed. Or they use their distro's packaging > system > to do the same thing. Dependencies between libraries are > maintained correctly. > > 2. Developers. A developer working on an aggregate package needs to > be able to edit & rebuild an aggregate package without rebuilding > everything every time. This is the scenario I believe we should > solve > with a few small additions to Cabal (see below). > > 3. Visual studio. VS has solutions, which are containers for multiple > packages, but the problem is that it doesn't want to *install* each > package as it builds, but it somehow needs to make each package > available to the others when building a chain of dependencies. > Again, > this is solved by the same small additions to Cabal. > > > As a developer, here is how I'd like to work on an aggregate package. > Suppose I have three packages mylib, myexe1, myexe2. I aggregate > these using a package bigpkg. I then arrange my tree like this: > > .../bigpkg/ > Setup.lhs > bigpkg.cabal -- build-depends: mylib, myexe1, myexe2 > mylib/ > Setup.lhs > mylib.cabal > src/ > myexe1/ > Setup.lhs > myexe1.cabal -- build-depends: mylib > src/ > myexe2/ > Setup.lhs > myexe2.cabal -- build-depends: mylib > src/ > > and I want to work on the whole blob like this: > > $ cd .../bigpkg > $ runghc Setup.lhs configure --local > $ runghc Setup.lhs build > > what does --local do? (we can choose a better name, incedentally): > > - it implies > --local-deps > --prefix=`pwd`/install > --packagedb=`pwd`/install/package.conf > > what does --local-deps do? > > - "configure" looks for dependencies in subdirectories of `pwd` > > - "configure" configures recursively. It passes > --prefix and other settings to each subdir > > - "build" command recursively builds dependencies that > are found in subdirectories, in dependency order. After building > each library dependency, it runs "setup install" in that subdir. > > - other commands just operate recursively. > > what does --packagedb do? > > - specifies a package database into which packages are registered > by "setup register" and "setup install" > > - you probably want to set GHC_PACKAGE_PATH too > > > -=-=- Summary -=-=- > > - Add --packagedb flag to Cabal. This just adds a -package-conf > to each invocation of GHC and ghc-pkg. > > - Add --local-deps flag to "setup configure" in the simple build > sysetm, which looks for dependencies in subdirectories, and causes > other setup commands to recurse into dependencies in the right > order. > > - Add --local flag which is just a macro > > > Pretty simple to implement, and does everything we want, I think. > > Visual Studio would do things slightly differently, but I believe > these facilities provide everything VS needs from Cabal. > > Incedentally, I want --local for converting GHC's libraries to Cabal. > We need to build & use directly from the build tree, which is what > --local does. > > Cheers, > Simon > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

2 1

RE: Shipments in Cabal
by Simon Marlow 09 Dec '05

09 Dec '05

I've read the thread, and I must admit I've been thinking along the same lines as Duncan. We don't need shipments. The problem is purely with developing aggregate packages, which we can solve with either tools or small additions to Cabal. (sorry, I intended this to be a short message, but it's turned out rather long :-/) I don't propose to change much, in fact I want to make the situation simpler: Cabal package == one library or one executable == one distro package == one distributable To aggregate packages, just create another package which contains only dependencies. This is how many distro packaging systems aggregate eg. all the KDE components into a single KDE package. 1. End users: they are served by this just fine. They just cabal-install the top-level package, and all the dependencies are magically downloaded and installed. Or they use their distro's packaging system to do the same thing. Dependencies between libraries are maintained correctly. 2. Developers. A developer working on an aggregate package needs to be able to edit & rebuild an aggregate package without rebuilding everything every time. This is the scenario I believe we should solve with a few small additions to Cabal (see below). 3. Visual studio. VS has solutions, which are containers for multiple packages, but the problem is that it doesn't want to *install* each package as it builds, but it somehow needs to make each package available to the others when building a chain of dependencies. Again, this is solved by the same small additions to Cabal. As a developer, here is how I'd like to work on an aggregate package. Suppose I have three packages mylib, myexe1, myexe2. I aggregate these using a package bigpkg. I then arrange my tree like this: .../bigpkg/ Setup.lhs bigpkg.cabal -- build-depends: mylib, myexe1, myexe2 mylib/ Setup.lhs mylib.cabal src/ myexe1/ Setup.lhs myexe1.cabal -- build-depends: mylib src/ myexe2/ Setup.lhs myexe2.cabal -- build-depends: mylib src/ and I want to work on the whole blob like this: $ cd .../bigpkg $ runghc Setup.lhs configure --local $ runghc Setup.lhs build what does --local do? (we can choose a better name, incedentally): - it implies --local-deps --prefix=`pwd`/install --packagedb=`pwd`/install/package.conf what does --local-deps do? - "configure" looks for dependencies in subdirectories of `pwd` - "configure" configures recursively. It passes --prefix and other settings to each subdir - "build" command recursively builds dependencies that are found in subdirectories, in dependency order. After building each library dependency, it runs "setup install" in that subdir. - other commands just operate recursively. what does --packagedb do? - specifies a package database into which packages are registered by "setup register" and "setup install" - you probably want to set GHC_PACKAGE_PATH too -=-=- Summary -=-=- - Add --packagedb flag to Cabal. This just adds a -package-conf to each invocation of GHC and ghc-pkg. - Add --local-deps flag to "setup configure" in the simple build sysetm, which looks for dependencies in subdirectories, and causes other setup commands to recurse into dependencies in the right order. - Add --local flag which is just a macro Pretty simple to implement, and does everything we want, I think. Visual Studio would do things slightly differently, but I believe these facilities provide everything VS needs from Cabal. Incedentally, I want --local for converting GHC's libraries to Cabal. We need to build & use directly from the build tree, which is what --local does. Cheers, Simon

1 0

RE: Shipments in Cabal
by Simon Peyton-Jones 09 Dec '05

09 Dec '05

| I think that's because we track dependencies on libraries but not | executables. So having one lib per package allows us to track library | deps correctly. | | Having more than one library in a package breaks dependency checking as | described in the wiki page. Crumbs. What is "a library"? Previously I'd understood that a package *was* a library. I think you are saying that Shipments contain N packages Packages contain N executables and M libraries Libraries contain N modules Do we really need FOUR levels? (Shipments, packages, libraries, modules) Joe is getting worried. Simon

2 1

RE: Shipments in Cabal
by Simon Peyton-Jones 09 Dec '05

09 Dec '05

That's helpful, but I still don't understand. I'm just Joe User. I'd like to install GTK. I'd like to download one thing and install it. I don't much mind whether it's called a "package" or a "shipment". Here are three things we can do a) Make it possible for a "package" to have multiple executables b) Invent "shipments", which can have multiple executables, and get rid of "packages" c) Have both "packages" and "shipments". Clearly (a) and (b) are essentially identical, modulo nomenclature. They seem simpler than (c). What is the merit of (c)? Would Joe User ever see or know about a package? Adding a summary of the reply to Duncan's wiki page would be useful I think Simon | -----Original Message----- | From: Krasimir Angelov [mailto:kr.angelov@gmail.com] | Sent: 09 December 2005 08:43 | To: Simon Peyton-Jones | Cc: Duncan Coutts; Haskell libraries | Subject: Re: Shipments in Cabal | | Cabal already supports multiple executables in one package but only | one library. | The problem is that the current implementation is just a hack. The | shipment allows to pack multiple packages in one tar.gz file and to | build them together. Each package will have only one library or only | one executable and this resumes the symmetry between executables and | libraries. I found that this simplifies the code a lot. | | Cheers, | Krasimir | | 2005/12/9, Simon Peyton-Jones <simonpj(a)microsoft.com>: | > | I started off from the assumption that "shipments" are necessary and | > | obviously beneficial. However after thinking about it for a while and | > | thinking through some of the implications (especially on dependency | > | resolution) I'm not not so convinced that we need shipments as such. | > | > I have not been following this thread much, but my original | > understanding was precisely that | > | > A Cabal package *is* the unit of distribution | > Indeed, that's what it is for | > | > I'm entirely unclear why new need some other larger unit. Yes, a Cabal | > package may depend on other Cabal package, but those dependencies are | > explicit in the package descr file, and Cabal-get can follow the links. | > Any larger unit (shipments) will also have dependencies that need to be | > followed, in just the same way, so I don't understand what has been | > gained. | > | > I'm probably missing something, but perhaps someone can write down the | > reasoning on Duncan's Wiki page? | > http://haskell.org/hawiki/Cabal_2fMultiPackageDistributables | > | > Simon | > | > _______________________________________________ | > Libraries mailing list | > Libraries(a)haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | >

2 1

RE: Shipments in Cabal
by Simon Peyton-Jones 09 Dec '05

09 Dec '05

| I started off from the assumption that "shipments" are necessary and | obviously beneficial. However after thinking about it for a while and | thinking through some of the implications (especially on dependency | resolution) I'm not not so convinced that we need shipments as such. I have not been following this thread much, but my original understanding was precisely that A Cabal package *is* the unit of distribution Indeed, that's what it is for I'm entirely unclear why new need some other larger unit. Yes, a Cabal package may depend on other Cabal package, but those dependencies are explicit in the package descr file, and Cabal-get can follow the links. Any larger unit (shipments) will also have dependencies that need to be followed, in just the same way, so I don't understand what has been gained. I'm probably missing something, but perhaps someone can write down the reasoning on Duncan's Wiki page? http://haskell.org/hawiki/Cabal_2fMultiPackageDistributables Simon

3 2

Shipments in Cabal
by Krasimir Angelov 08 Dec '05

08 Dec '05

Hello Guys, I have started developing Shipments in Cabal. It is working like it was discussed previously. When there are multiple *.cabal files, in the directory where the Setup.lhs lies, then they all will be build in dependency order. Packages that contain both executables and libraries are deprecated. In order to keep the backward compatibility the package description parser returns a list of PackageDescription. In the list there is one element for the library and one element for each executable. The package name for the executables is equal to the "executable" field in the corresponding stanza in the package description file. The trouble that I see is with the bindir, libdir, etc directory names. They all may depend on $pkgid value which is different for each package in the shipment. The consequence is that by default all binaries will be installed in their own directories. I think it is better to install them in common directory instead. It might be better if we were able to use $shipment variable instead of $pkgid. Another possible usage of is in "sdist" command. By default the "sdist" command is building the ${pkgid}.tar.gz archive. In presence of multiple packages I think it should build one common package: ${shipment}.tar.gz. The problem is how to guess the $shipment value. There are some ideas: a> The shipment name might be kept in some special file. b> In HSQL I am using package names like: hsql, hsql-odbc, hsql-mysql, ..... One solution is to use the common prefix in the package names as shipment name. When there is only one package, then the shipment name will be equal to the package name. The advantage is that, when the shipment name is encoded in the package name, then for the user it will be easier to find the package sources. The drawback is that we have to force some restriction on the package names. c> Another solution is to use the name of the top level directory. The drawback is that the user can't rename the top level directory. Any ideas? Cheers, Krasimir

3 5

Cabal fails to install package with executables
by Alexey Rodriguez Yakushev 07 Dec '05

07 Dec '05

Hi! I am making a Cabal package containing executables. Most options to the Setup.hs script work except installation. The error seemed so obvious that I thought it my own. But trying with one of Cabal's testcases I discovered the same error. Take the wash2hs example found in the tests directory. Taking a quick look at (wash2hs.cabal) http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/Cabal/ tests/wash2hs/wash2hs.cabal?rev=1.5;content-type=text%2Fplain We can see that - The sources live in the hs directory - The main hs file is WASHMain.hs and - The executable is wash2hs I run "configure" and "build" with no problems, but when calling "Setup.hs" with "install -v" I get: -------- $ runghc Setup.lhs install -v Installing: /opt/lib/Wash-2hs-1.4.34 & /opt/bin Wash-2hs-1.4.34... copy dist/build/wash2hs to /opt/bin/wash2hs *** Exception: dist/build/wash2hs: copyFile: does not exist (No such file or directory) --------- Although the built binary is placed in dist/build/hs, Cabal insists on reading the binary from dist/build for installation. I am running the 6.4.1 GHC generic binary for x86 linux systems. I downloaded the test case from the 1.0 distribution of Cabal, I checked that it is the same as in CVS. I welcome all hints. Cheers, Alexey

2 1

Compiling haskell-src-exts with -prof
by cschmidt＠deds.nl 06 Dec '05

06 Dec '05

One of the packages that I use depends on Language.Haskell.Hsx from haskell-src-exts. I want to profile my code, so I need to compile Language.Haskell.Hsx for profiling. I tried to figure out how to compile haskell-src-exts with -prof, but so far I could not. Can anyone point me in the right direction? I am building on Windows with GHC 6.4, if that matters. Thanks Cyril

3 2