August 2006 - cabal-devel

Re: Cabal patch: Add setup haddock --hoogle option
by Henning Thielemann 21 Aug '06

21 Aug '06

On Sun, 20 Aug 2006, Neil Mitchell wrote: > Hi, > > The attached patch adds support for the --hoogle option to the haddock target. > > Tested on the base package, now running: > > runhaskell Setup haddock --hoogle > > Gives the file base-2.0.txt which can then be fed into Hoogle properly. Is it a good idea to tell this by an option to 'Setup haddock'? This means manual intervention on each package which shall be used by Hoogle.

2 1

Re: Extending Windows support
by Krasimir Angelov 21 Aug '06

21 Aug '06

Hi Esa, All these things are really useful for all Windows developers. I didn't yet proposed this only because it is too Windows and GHC specific but this isn't a reason not to have them. Actually if we have support for resources in Cabal then one day I would like to see resource editor in Visual Studio for Haskell. One interesting feature would be to have automatic generation for VERSION resource that to be prepopulated with the version and copyright information from Cabal. We already have generation for one Haskell module why not to have generation for one resource file. You propose to extend the cabal description with one additional stanza type like the executable stanzas but I would recall that the current model with one library and multiple executables is broken. I vote again for a redesign where to have only one library or one executable in a given package. After that with the addition of DLL we will have three types of packages: library, executable or DLL. I didn't looked at implementation but I saw a couple of messages in this mailing list about the introduction of configurations in Cabal. Are they working with executables? Cheers, Krasimir > Esa Ilari Vuokko <eivuokko(a)gmail.com> writes: > > > 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 > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel(a)haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel >

1 0

New index format patch
by Paolo Martini 20 Aug '06

20 Aug '06

Hello, OK good news! Here's a patch to make cabal-install use the tarball index format discussed in the previous email. (I finally gave up in trying to do a whole refactoring, which I started from scratch many times, and started a more seamless integration of ideas in the existing code.) Since we don't rely on any program to do the QA, check that the packagename directory and the name of the tarball and the name inside the .cabal file are the same case-sensitively before adding it. The instructions for those eager of making a repository: 1. mkdir -p packages/packagename 2. cp package-version.tar.gz packages/packagename/ 3. GOTO 1 for each package you want in the repository 4. tar --create --gzip --file packages/00-index.tar.gz --exclude '*.tar.gz' --directory packages/ . # don't miss the last dot in the above command! I need help on one matter--I am not sure about pkgUrl: If I enable multiple repositories and scan the local hierarchy after having downloaded the files from all of them, it becomes impossible to map files to urls. So the solution could be having multiple repositories whose names are the urlEncoded strings of the actual repositories' urls. If having just one repository doesn't bother anyone too much, I'd like to know what do you think it's worth doing next. Also, I'd like to have some feedback on this patch, I am not sure I did not make any mistake! Peace, Paolo. P.S. Lemmih, I did make the little modification to TarUtils.extractTarFile dcoutts suggested, do you think it is okay? Another possibility could be passing the directory to `cd' to, via the -C option, I'd like to hear what you think. --

2 1

Re: Building cabal with cabal fails?
by shelarcy 20 Aug '06

20 Aug '06

On Thu, 17 Aug 2006 21:48:13 +0900, Neil Mitchell <ndmitchell(a)gmail.com> wrote: > darcs get http://darcs.haskell.org/packages/Cabal --partial > cd Cabal > runhaskell Setup configure > > And I get the error: > > ./Distribution/Simple.hs:61:1: lexical error > > Should this work? If not, what should I be doing. If Distribution directory is in the same directory, runhaskell find and use that. So, Setup.(l)hs import Distribution directory's source file, not ghc's Distribution/*. And ./Distribution/Simple.hs uses C preprocessor, so that cause lexical error. If you want to solve this error, you should use cpp option like this. runhaskell -cpp Setup.lhs configure runhaskell -cpp Setup.lhs build runhaskell -cpp Setup.lhs install Or you have to change to add below pragma per file that you can see lexical error. {-# OPTIONS -cpp #-} -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

2 1

Re: [Haskell-cafe] cabal specify a "tested version", ghci target?
by Duncan Coutts 20 Aug '06

20 Aug '06

On Sat, 2006-08-12 at 03:52 +0200, Marc Weber wrote: > 1.) > I know I can use > Build-Depends: lib == <version>, lib2 < version, lib3 >= version > and so on. > > Do you think it would be useful to introducue some notation to indicate > a "tested with" ? > > Reason, purpose: I think its sometimes the case that a author/ mantainer > is quite busy with other projects and misses that some dependencies > break things.. If you want to try out you're left with some compiler > errors and a dependency and have to try out which version works. > > I would propose using this syntax: > lib-1.3 >=1.1 > to indicate that lib 1.1 is required at leeast and tested with up to > 1.3.. Cabal might then give a warning if you try to use 1.4 or greater > "using newer version than tested" or similar.. > > What do you think? > Would this be useful? Well there is actually already a "tested-with:" field that you can put in a .cabal file, however at the moment it refers only to the Haskell implementation, eg ghc-x.y, hugs-x.y etc not to versions of libraries. Yes, I think it's a quite reasonable argument to extend this to include exact versions of libraries that it has been tested with. What do others think? Duncan

2 1

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