- Libraries - Haskell.org

re: Cabal interface changes proposal
by isaac jones 26 Nov '04

26 Nov '04

Hi all, I like the idea of adding a layer on top of the current cabal to add "shipments"... this would solve the problem of packages like gtk2hs and wxhaskell mentioned by Duncan Coutts, and allows us to keep the core cabal simple. Since it won't affect the core interface, I'll just push that on the stack and worry about it later. Krasimir suggested that a single cabal package should only have one executable, but I don't agree. I can see the reasons for keeping a one-to-one correspondence between a cabal package and a Haskell package, but I actually really like the way cabal treats executables right now. It's much simpler than libraries since it doesn't require a registration step or anything. It just needs to know where to find main and what to call the binary. As Duncan and Simon pointed out, multiple libraries is actually a more complicated story. So I would say that for now, let's keep the basic structure the same, a single library and multiple executables are allowed in a cabal package file, and hopefully we'll find time to implement "shipments" later so we can bundle together several libraries. I hope that won't hurt anyone too badly in the short term. I'll go ahead and perform the other changes mentioned. Sound OK? peace, isaac

3 2

RE: Cabal interface changes proposal
by Simon Marlow 26 Nov '04

26 Nov '04

On 26 November 2004 05:29, isaac jones wrote: > I like the idea of adding a layer on top of the current cabal to add > "shipments"... this would solve the problem of packages like gtk2hs > and wxhaskell mentioned by Duncan Coutts, and allows us to keep the > core cabal simple. Since it won't affect the core interface, I'll > just push that on the stack and worry about it later. > > Krasimir suggested that a single cabal package should only have one > executable, but I don't agree. I can see the reasons for keeping a > one-to-one correspondence between a cabal package and a Haskell > package, but I actually really like the way cabal treats executables > right now. It's much simpler than libraries since it doesn't require > a registration step or anything. It just needs to know where to find > main and what to call the binary. As Duncan and Simon pointed out, > multiple libraries is actually a more complicated story. Personally I think moving multiple executables up to the shipment layer would be conceptually simpler, but it's not that big a deal. You're the boss! > I'll go ahead and perform the other changes mentioned. Sound OK? Sure. Sorry I haven't pushed back my changes yet, still trying to hack GHC around with the new package story. It's a lot more involved than I thought, and I'm taking the opportunity to do some cleanup in GHC at the same time. Also I need to update Cabal to talk to GHC's new ghc-pkg tool, which uses the InstalledPackageInfo syntax for packages. Cheers, Simon

1 0

RE: printf
by Simon Marlow 25 Nov '04

25 Nov '04

On 23 November 2004 20:34, Lennart Augustsson wrote: > Being an old C programmer I'd like to suggest a library, Text.Printf, > for C printf() style formatting. > > For example > > do > printf "Hello, world\n" > printf "%s, cruel %s\n" "Goodbye" "world" > printf "pi is about %10.8f\n" (pi::Double) > > I have a Haskell 98 implementation of this function if people feel > that it would be useful. I'd like to pull this in, or something like it. IMHO, the lack of static type safety is outweighed by the shear convenience, and it's too small to provide as a separate library. It'd be nice to have hPrintf :: (PrintfType a) -> Handle -> String -> a too. Cheers, Simon

5 4

printf
by Lennart Augustsson 23 Nov '04

23 Nov '04

Being an old C programmer I'd like to suggest a library, Text.Printf, for C printf() style formatting. For example do printf "Hello, world\n" printf "%s, cruel %s\n" "Goodbye" "world" printf "pi is about %10.8f\n" (pi::Double) I have a Haskell 98 implementation of this function if people feel that it would be useful. -- Lennart

3 7

RE: Cabal interface changes proposal
by Simon Marlow 23 Nov '04

23 Nov '04

On 23 November 2004 09:04, Krasimir Angelov wrote: > I am strongly advocating to have one to one > correspondence between Cabal packages and Haskell > packages. It would be even simpler if in each Cabal > package we have only one library or only one > executable. I like the Simon's proposal of shipments. > If we need a package with one library and multiple > executables we can use shipment too. Currently we have > Setup.description for each package. I propose to > change the name to Package.description and to > introduce Shipment.description file. The latter will > contain the name of shipment and the list of > Package.description files in it. The Cabal package > should export defaultMain and defaultShipmentMain > functions, where the former builds a single package > while the latter builds a shipment. Sounds good. I like the fact that the existing package description can be simplified. Presumably the Setup.lhs in the shipment works by invoking Setup.lhs from each of the packages, in which case we'll need to expand Cabal with a notion of a local package database. Perhaps: ./setup configure --pkg-db=PATH satisifies dependencies using packages from PATH, layered on top of the global & user packages as normal. ./setup register --pkg-db=PATH registers in the package database at PATH. The default is still to register in the global db, or the user db if --user is given. We need this to support the "directory of packages" idea too (PATH can be either a directory or the name of a file containing the database). Cheers, Simon

1 0

Cabal interface changes proposal
by Isaac Jones 23 Nov '04

23 Nov '04

Hi Gang, I would like to make a few interface changes to Cabal, but I want to get some feedback first, and to give a heads-up. By "target" I mean "place where the package will end up getting installed" rather than the build machine, which may be different. -= New commands =- ./setup copy (similar to ./setup install, with or without a prefix. Never runs register or postinst) ./setup test (runs a user-supplied IO () function) ./setup postinst (guaranteed to run on the target after register, runs a user-supplied IO () function) -= Changes to existing commands =- ./setup install now will not have the --install-prefix flag. Use "copy" instead. Install will always run register and postinst. ./setup register may or may not run on the target machine -= Changes to package description file =- I can imagine a cabal package (wxhaskell) which has more than one "haskell package" / library in a single source tree. We might like to have more than one "haskell package" per "cabal package". That is, installing a single cabal package, Foo, might make "-package bar -package bang" available to the compilers. So I propose that we add the ability to have multiple libraries, just as we can currently do multiple executables. Right now, there's no great way to do this, besides perhaps having multiple directories with multiple Setup.lhs files. The downside to this is that it might make the description file a little more complex, though in the simple case, it won't change much. What do folks think? -= Notes =- Copy function: I'm not crazy about the way that "install" has different behavior depending on the --install-prefix flag. In particular, without the flag, it doesn't register, with the flag, it does. This is convenient, but inconsistent. I hope that this command will clean it up. It was Ian Lynagh's idea. Postinst: This is related to the discussion about ghc-pkg on the libraries list. The idea is to have a command that's guaranteed to run on the target. This frees up the register command to be more flexible. By default, postinst will do nothing, just like "./setup test". peace, isaac

2 1

RE: Cabal interface changes proposal
by Simon Marlow 22 Nov '04

22 Nov '04

On 21 November 2004 01:15, Isaac Jones wrote: > I would like to make a few interface changes to Cabal, but I want to > get some feedback first, and to give a heads-up. > > By "target" I mean "place where the package will end up getting > installed" rather than the build machine, which may be different. > > -= New commands =- > > ./setup copy (similar to ./setup install, with or without a > prefix. Never runs register or postinst) > ./setup test (runs a user-supplied IO () function) > ./setup postinst (guaranteed to run on the target after register, runs > a user-supplied IO () function) > > -= Changes to existing commands =- > > ./setup install now will not have the --install-prefix flag. Use > "copy" instead. Install will always run register and postinst. > > ./setup register may or may not run on the target machine This all looks good to me. > -= Changes to package description file =- > > I can imagine a cabal package (wxhaskell) which has more than one > "haskell package" / library in a single source tree. > > We might like to have more than one "haskell package" per "cabal > package". That is, installing a single cabal package, Foo, might make > "-package bar -package bang" available to the compilers. > > So I propose that we add the ability to have multiple libraries, just > as we can currently do multiple executables. > > Right now, there's no great way to do this, besides perhaps having > multiple directories with multiple Setup.lhs files. The downside to > this is that it might make the description file a little more complex, > though in the simple case, it won't change much. What do folks think? First of all, I should say that I doing see an urgent need for this. Packaging systems such as Debian, *BSD & Gentoo manage dependencies and can build multiple packages in the right order just fine, and have support for "collection" packages (eg. installing "kde" causes a bunch of sub-packages to be installed). Introducing this functionality in Cabal would be redundant on these systems. My feeling has always been that we shouldn't duplicate functinoality that is available in a good package system. Given that, if you really want to do this, then here are my thoughts: basically it would mean introducing another "layer" of packaging, albeit one that lives only at the Cabal level, which Haskell compilers know nothing of. Here are some issues that initially spring to mind: - Packages in this layer should be called something other than packages, to avoid confusion (I'll call them shipments, for now). - Should the shipment have a name of its own? - Should it have a version? - Presumably the packages in a shipment depend on each other. That means we need to "temporarily" install packages so we can build against them. This isn't something that the current package proposal really supports, but I think it would be useful. Cheers, Simon

2 1

RE: proposal for ghc-pkg to use a directory of .conf files
by Simon Marlow 22 Nov '04

22 Nov '04

On 21 November 2004 00:56, Isaac Jones wrote: > The systems that would want to do this kind of thing, such as Debian, > have other mechanisms for deciding whether packages conflict, etc. IIRC, this is the argument I just used against adding support for multiple libraries in Cabal, so I guess I agree :-D > Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque > interface to the packaging system. What are the advantages to this? Well, for one thing it allows us flexibility in how we store the package database. In GHC, I'm using the show/read form of [InstalledPackageInfo] to store the database, but it'd be nice if I could use binary serialisation in the future. To support a directory of config files, we don't have to expose the complete format, though. As long as hc-pkg can process the InstalledPackageInfo to produce the native format into a file, then we just ship that file with the distribution. So I'm fine with this, as long as we're not specifying the contents of the *.conf file. Cheers, Simon

1 0

RE: proposal for ghc-pkg to use a directory of .conf files
by Simon Marlow 20 Nov '04

20 Nov '04

On 09 November 2004 17:36, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> On 08 November 2004 18:47, Duncan Coutts wrote: >> >>> We can use ghc-pkg at the build / install-into-temp phase to create >>> the $(package).conf files under >>> $TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d/ and then final >>> installation is jsut merging files without any post-install calls to >>> ghc-pkg to modify installed files (ie the global ghc package.conf >>> file) >>> >>> So we can still keep the abstraction of $HC-pkg and gain simpler >>> packaging stuff. >> >> Ok, sounds reasonable. >> >> I'm going to be working on the package support in ghc and ghc-pkg to >> improve support for Cabal, so let's do this at the same time. > > As a Debian packager, I like the idea of changing the way HC-PKG > handles individual packages. > > The question in my mind is whether we want to execute any code on the > install target. Previously, I have thought of "./setup register" as > being a step that happens on the target, no matter what. So if Marcus > Makefile wants to do something specifically for the target at install > time, this is where he could do it. > > If we go this route and have the package registration happen at > install-in-temp time, then we don't have any standard way to run a > post-install script. Some people may prefer that we never execute > anything from Cabal on the target, but I would prefer to leave that > ability. > > One solution would be to move the registration step into > install-into-temp time, as above, but to add another standard command > to Cabal like "./setup postinstall" and maybe some others "preinst, > prerm, postrm" as in Debian. > > This would solve both problems; haskell packages installed with a > packaging system like Debian would usually just be moving files into > place, but if Marcus or Angela really needed to run something on the > target, this is how they'd do it. If ./setup register isn't going to run at install time, then I agree we might want ./setup postinst too. There's another thing that bothers me though: when you install a package using hc-pkg, a number of checks are made: 1. there isn't already a package with that name/version 2. If the package is to be exposed, then the modules provided by the package don't overlap with another exposed package. 3. if an older version of the package is already exposed, then the older one is supposed to be hidden in favour of the new one Since with the proposed change hc-pkg isn't running on the target system, it can't make any of these tests. GHC can detect at run-time that you have overlapping packages, but then it might not be possible to make changes to the package database (you might need to 'su' in order to do it). Cheers, Simon

2 1

Cabal - C sources in a subdirectory
by Einar Karttunen 17 Nov '04

17 Nov '04

Hello I have problems with Cabal failing to build simple packages if C-Sources are inside a subdirectory. With a Setup.description like: Name: Foo Version: 0.1 License: LGPL Modules: Foo Exposed-Modules: Foo Extensions: ForeignFunctionInterface C-Sources: c_src/foo.c Build creates c_src/foo.o => dist/build/foo.o (from the C-Sources build instruction in Distribution.Simple.Build). In the later stage it tries to look for the object file in dist/build/c_src/foo.o which fails. A complete minimal example is at http://www.cs.helsinki.fi/u/ekarttun/haskell/cfail.tar.gz - Einar Karttunen

2 4