- cabal-devel - Haskell.org

expanding use of the Program abstraction
by Isaac Jones 20 Aug '06

20 Aug '06

I wonder if someone is interested in expanding the use of Program inside Cabal. There's a type in cabal Distribution.Program.Program which does some nice stuff for describing programs internally for Cabal. A program is basically a name, a location, and some arguments: -- |Represents a program which cabal may call. data Program = Program { -- |The simple name of the program, eg ghc programName :: String -- |The name of this program's binary, eg ghc-6.4 ,programBinName :: String -- |Default command-line args for this program ,programArgs :: [String] -- |Location of the program. eg. \/usr\/bin\/ghc-6.4 ,programLocation :: ProgramLocation } deriving (Read, Show) One nice thing about using it is that any program that is registered with Cabal will get some "configure" and ".cabal" helpers like --with-foo-args --foo-path= and extra-foo-args: There's also good default behavior for trying to find "foo" in PATH, being able to override its location, etc. There's also a hook for adding programs in a Setup.lhs script so that you get these flags and such so that you don't have to write all the PATH logic inside Setup.lhs. The only thing that's wrong w/ Program is that its not used all over Cabal :) Tools like ranlib do use it, I think, but not all preprocessors and the compilers don't use it. Does anyone feel like digging around in Cabal and expanding the use of Program so that we have more consistent flags and such? Some basic TODOs are here: http://hackage.haskell.org/trac/hackage/search?q=Distribution.Program&ticke… peace, isaac

1 0

Build-depends usefull for Cabal?
by Einar Karttunen 20 Aug '06

20 Aug '06

Hello Would having a build-depends in addition to depends make sense in Cabal? Most package systems make this distinction. I can think of two use cases for this: 1) TH libraries (if GHC starts supporting avoiding to link to them) * I am packaging a library of TH utility functions for class deriving. Most programs need this only on build time and don't need it at runtime (except for GHC linker reasons). 2) It would make tool dependencies clearer * It is currently impossible to depend upon a tool at runtime. But is this needed for Cabal? 3) It would make translating dependencies to other package systems easier. This is not high priority at any rate. The build-depends field would default on the value of depends. - Einar Karttunen

3 2

darcs patch: Add initial support for --enable/disable-library-vanilla
by Isaac Jones 20 Aug '06

20 Aug '06

Patches from Jeremy Shaw. Duncan, can you look at these and apply?

3 9

Restricted commandline lenghts
by Esa Ilari Vuokko 18 Aug '06

18 Aug '06

Hi, Ticket #19 [1], and maybe some big projects in general, need to be able to invoke ar/ld so that we don't run into issues in commandline lenght. (And in theory, compiler's as well, but we that'd require the dreaded deps analysis.) I think this is major feature we should resolve before GHC 6.6 goes out. It affects significantly some libraries, at least gtk2hs, and I can see real size benefits on some of my own libraries as well. I posted patch to fix this in some cases for Windows [2], but upon talking about it with Duncan, in irc, there's few exta points: * Some unixy shells apparently have restrictions as well, so this shouldn't be just Windows. * On my old implementation, I just split the commandlines by filecount, not according to actual space the paths take. Is this a major point? It can affect the number of tool invokations quite radically. * The algorithm should really be parametriseable because it is, I believe, in all cases heuristic. As how to proceed on implementing this, I'm a bit unsure. * Because of unicode conversion issues, I am not entirely sure if we can accurately know the length of commandline, atleast in Windows. Or going for the bad case, 4 bytes per character gives us a lot of setback in common case. * I think the common way to workaround this is by using xargs with some constant number per params (much like my current algos). * I think there is a diffrence between complexities, because with ar we really want to do append, but with ld we can do a tree-style build. I haven't benchmarked this. * This might be useful to generalise into library function(s). I could use some advice or experiences from other buildsystems. If nobody else steps up, I'll probably implement some choice (but I'm only prepared to test it in Windows.) [1] http://hackage.haskell.org/trac/hackage/ticket/19 [2] http://www.haskell.org/pipermail/cabal-devel/2006-May/000006.html Best regards, --Esa Ilari Vuokko

2 2

darcs patch: Try to support TH with profiling. See ti... (and 1 more)
by Duncan Coutts 18 Aug '06

18 Aug '06

Wed Aug 2 18:59:22 BST 2006 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Try to support TH with profiling. See ticket #91. This needs testing. Fri Aug 18 02:04:49 BST 2006 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Add xargs function and use it when linking. When using GHC's --split-objs we end up with lots of files to link. This can mean overflowing the maximum length of the command line when invoking ar or ld. On windows the maximum length is 32k. On other systems it's not a great deal more. GHC currently deals with this problem by using xargs. This patch does more or less the same.

1 0

Cabal with Generating files (Was: Cabal Questions
by shelarcy 17 Aug '06

17 Aug '06

On Fri, 18 Aug 2006 06:05:36 +0900, Esa Ilari Vuokko <eivuokko(a)gmail.com> wrote: > On 8/17/06, Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> wrote: >> We don't yet have a generic preprocessor support system. It is indeed >> part of the plan. I know I'll need it for Gtk2Hs. > > What about UserHooks.hookedPreProcessors? The code seemd like > it could work, but I haven't tested it. I think changing Setup.(l)hs definition with UserHook is very strong, but this approach is too complex to specify just generating file from other resources by only one tool. I think cabal must support to write using self preproccesser definition in *.cabal files like this. name: hdirect version: 0.1 (snip) othermodules: ComPrim, AutoPrim generatable: ComPrim g-sources: ComPrim.idl g-tool: ihc g-option: -fno-export-list -fappend-interface-short-name -fno-qualified-names -fno-imports -fno-export-lists -fkeep-hresult -fout-pointers-are-not-refs generatable: AutoPrim g-sources: AutoPrim.idl g-tool: ihc g-option: -fno-qualified-names -fno-imports -fno-export-lists -fkeep-hresult -fout-pointers-are-not-refs This is rough sketch. But I think this is useful for discussion about "Cabal with Generating files". -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 0

Extending Windows support
by Esa Ilari Vuokko 15 Aug '06

15 Aug '06

Hi, There's few things Cabal could handle for Windows-based Cabal users. I hope to implement them if there's agreement that they are sensible additions into Cabal. All of them can of course be done in Setup.hs, but that's just annoying. This is rather ghc-specific, because that's what I use. And most of this doesn't probably matter for compilers that aren't producing binaries. * DLLs Rationale: Building DLLs is fairly common in Windows, they are a most common way to extend many appliations via COM or other plugin-like systems. Note: this has nothing to do with producing dynamically linked haskell packages/libs. Rather it almost identically to producing .exe, except that main won't be called. Todo: Easiest way seems to be to add new part to package config, much like executables, extending executable-list to contain DLL info might also be doable, but less clean. Important bits I can think of: * passing --mk-dll to ghc * being able to specify .def file and passing it through ghc to dlltool (--optdll--def --optdllPATH/TO/A.DEF) * Possibly building import library by calling dlltool with .def and right options (means we have to add new program: dlltool) * Installing import lib...well dunno about this. Example how it can be done right now: http://darcs.haskell.org/vshaskell/vs_haskell/Setup.lhs (note that this script builds import lib for diffrent dll than it builds) * Resource (scripts) Rationale: Resources are embedded (binary) data sections in executables. In Windows these can be (easily) edited after the exectuable has been linked, and there's many APIs that can use them. Also some important information can be encoded in them, like versioning, icons, manifest files. I am not sure about already compiled resource files, I recall some dialogeditors producing object files, but they are probably wrong format object files as long as ghc works on top of gnu toolchain. Todo: Mainly Cabal needs to know and invoke a tool very much like c-compiler. For mingw (and probably cygwin) this would be windres.exe. We probably also need to get the tool into ghc binary distribution. Example: I don't know anyone doing this using Cabal. Best regards, --Esa Ilari Vuokko

1 0

issues with configurations
by Duncan Coutts 11 Aug '06

11 Aug '06

Following long discussions on #haskell, here's some tricky cases we thought of with configurations. 1. build-depends: base configuration: debug build-depends: HUnit>=1.0 configuration: package(HUnit>=1.1) ghc-options: -DBlah The issue with this is what the "package(HUnit)" test means. Under one interpretation it just tests if that package is available (ie already installed), not if it's actually going to be used in this package. Under the other interpretation this can't be expressed since HUnit is not a top level dependency. Alternatively we could evaluate the configurations in order, in which case we've added HUnit>=1.0 to build depends before checking package(HUnit>=1.1). But making it order-dependent is ugly. 2. build-depends: base configuration: package(hdbc) build-depends: hdbc configuration: package(hsql) build-depends: hsql This is not ideal since it suggests that we will just pick up optional dependencies on packages if they are available with no control from the user as to whether they want those dependencies. This also means that the order in which you install packages can affect which features are enabled which makes the use of a dep resolver like cabal-install less intuitive as it becomes hard to predict how the packages will end up getting built. Incidentally this conflicts with distro package mangers like Gentoo's which specifically bans automatically picking up optional deps. It requires that all optional deps be specified before hand and be configurable by the user. This would also be difficult for binary package managers like debian as the debian package would just have to statically decide if hdbc or hsql or both will be used. Again, one option is to ban this on account of neither dep being mentioned in the top level build-depends. A better way to express this dependency might be: build-depends: base configuration: hdbc build-depends: hdbc configuration: hsql build-depends: hsql This means that we have flags "hdbc" and "hsql" and the user must specify at configure time --enable-hdbc or --disable-hdbc This way the optional dependency is not automatic and can be changed by the user. It's perfectly ok for there to be a default setting for the flag so long as the user can override it. This is much like Gentoo's USE flag system. 3. build-depends: base configuration: package(base<=1.0) build-depends: fps>=0.8 This one is ok. Is there a better way to do what we want without getting the bad cases? I am of the opinion that it makes little sense for conditional package tests to be of what packages are available in the environment rather than packages that have actually been chosen for this package. Remember that we can have multiple versions available so here's a case where 1. falls over. Here's case 1. again: 1. build-depends: base configuration: debug build-depends: HUnit>=1.0 configuration: package(HUnit>=1.1) ghc-options: -DBlah Suppose we have HUnit 1 and 2 installed. Suppose our package depends on another package which needs HUnit-1. With the debug flag enabled we depend on HUnit>=1.0. To pick a consistent HUnit version we must use 1.0 since we can't have two versions of the same package (even ghc's recent support for this doesn't help if HUnit gets used in the interface since the types would not match). So we pick HUnit-1.0. Now the configuration test "package(HUnit>=1.1)" is still true because there is version 2 available, even though we're not using it! This is not an intuitive semantics. If we say that package() tests must refer to packages we're going to actually build against on then this is fine and we get what the package author probably meant. So this suggests we should limit package() tests to packages that we depend on or might depend on. But for 1. we still have the issue of the order of evaluation of configuration stanzas being significant because they can add packages to build-depends which other stanzas may test. In gentoo such a dependency might be expressed as: DEPEND="debug? ( HUnit>=1.0 )" but then the action dependent on the version of HUnit that we picked would be done later. So there's a clear ordering. So one solution is to not allow build-depends in conditional stanzas but to specify conditional depends up front. build-depends: base, debug? ( HUnit>=1.0 ) configuration: debug ghc-options: -DDEBUG configuration: package(HUnit>=1.1) ghc-options: -DBlah or: build-depends: base > 1.0 || ( base <= 1.0 && fps >= 0.8 ), os(windows)? ( Win32 ), os(linux)? ( inotify ) configuration: package(fps) ghc-options: -DOLD_FPS configuration: package(base < 1.1) hs-src-dirs: compat So I guess the suggestion is that all deps are given up front and resolved. Then depending on what deps were chosen we can have other effects on the build like specifying extra src dirs or flags or whatever, but not specifying any more build-depends. So the order of checking configurations is independent again. Ok I've gone on long enough. Duncan

3 11

ghc-pkg bug? possible cabal workaround?
by Isaac Jones 11 Aug '06

11 Aug '06

Heya Simon. I've noticed that in ghc 6.4.2, ghc-pkg doesn't create the file (or maybe just the directory) when trying to register a package: rm -r ~/.ghc/i386-linux-6.4.2 /usr/bin/ghc-pkg update .installed-pkg-config --user ghc-pkg.bin: /home/ijones/.ghc/i386-linux-6.4.2/package.conf: getPermissions: does not exist (No such file or directory) Cabal could try to create the file & directory w/ something like what you have in ghc-pkg plus createDirectoryIfMissing, but I'm a bit nervous of using the System.Info stuff since I know it's pretty new. I'd like to keep cabal working w/ ghc 6.2. We can probably solve this by creating a ghc 6.3 version of Distribution.GHCPackageConfig.maybeCreateLocalPackageConfig and calling it around line 149 of Distribution.Simple.Register. Here's how ghc-pkg generates the filename: appdir <- getAppUserDataDirectory "ghc" let subdir = targetARCH ++ '-':targetOS ++ '-':version archdir = appdir `joinFileName` subdir user_conf = archdir `joinFileName` "package.conf" user_exists <- doesFileExist user_conf I'm not sure where the bug is in ghc-pkg; it's not obvious to me, but it'll probably be obvious to you. Should we implement a cabal workaround? Has anyone complained about this? peace, isaac

2 1

Multiple dependencies on the same package (was discussion on #haskell)
by Einar Karttunen 10 Aug '06

10 Aug '06

Hello There was a discussion about the semantics of the package dependencies on #haskell. Continuing here for clarity. build-depends: foo > 1 && < 3 vs build-depends: foo > 1, foo < 3 and the same with configuration stuff: packages(foo >1 && < 3) vs packages(foo > 1) && packages(foo < 3) Current Cabal and the configurations patch interpret these as: * "packages(foo >1 && < 3)" * there exists a package foo such that the version is >1 and <3 * "packages(foo > 1) && packages(foo < 3)" * there exists a package foo such that the version is >1 *and* * there exists a package foo such that the version is <3 This means that the semantics are very simple, each package and depend can be handled in isolation. This has not caused problems but should be documented more clearly. The alternative solution is to make package names have per-configuration and per-build-depend-line specific scope and add an environment to the semantics. This would eliminate a class of errors, but on the other hand make reasoning about the semantics harder. e.g. is this a tautology: configuration: (package(foo > 10) || flag) || (package(foo < 10) || !flag) Under the current semantics it is a tautology, since regardless of how the foo match goes we have: (x || a) || (y || !a) <=> (x || y || (a || !a)) <=> True With the new semantics this would depend on the evaluation strategy. Clearly there is no version of foo which satisfies the dependencies. - Einar Karttunen

2 1