January 2007 - cabal-devel

[Conal Elliott] Re: getting cabal to pass more info to haddock
by Isaac Jones 15 May '07

15 May '07

3 7

Why is there a cabal file at all?
by Marc Weber 12 Mar '07

12 Mar '07

Sorry for this stupid question put there must be reasons I don't know. I've been thinking a lot about packaging/ dependency handling etc the last days. Haskell is one of the most typesafe and expressive languages, right? Now we need a haskell compiler/ interpreter to run Setup.hs. So why not combine both and use some kind of cabal combinator library? I'll try to implement a prototype although knowing there are lots of people knowing how to do this better. module Setup where import CabalBuildProposal helloWorld = haskell-executable $ do setName "helloworld" sourceDir "src" $ mainIs "HelloWorld.hs" addDependencies = case stringOption "pretty_print_lib" of "A" : [LibVersionRange "A" "1.0 - 2.0"] "B" : [LibVersionRange "B" "1.0 - 2.0"] package = do setAuthor = "Marc Weber" addAtom helloWorld preprocess = defaultHaskellPreprocess build = preprocess >>= defaultHaskellBuild rpm = build >>= defaultRPM install = defaultHaskellInstall haddock = defaultHaddock targets = [ ("preprocessOnly", preprocess) , ("build", build ) , ("install", build >>= install) , ("rpm", rpm ) , ("haddock", preprocess >>= haddock) ] main = do handle package targets using preprocessors might be done in this way: addExposedModules $ map preprocessByCPP $ modulesByRegex "src/**/*.hs" I think you get the idea why this approach might be much more powerful? The package mantainers of ght2hs and wkhaskell have both trouble makeing their project work with cabal.. So why do we limit ourself using cabal files like the existing ones? I think you've noticed the line addDependencies = case stringOption "pretty_print_lib" of This should use the correct dependency if the option has already been set by cmdline or config file else ask the user or choose the first but noticing the user by printing a message like this: unset option "pretty_print_lib", defaulting to "A" preprocess should be passed all configuration options and return a list of source files, build should get the list of source file and return a list of executables which are installed by install straightforward, isn't it? Thus the right build/ install whatsoever step would be choosen not by defining hooks but by the haskell type system. This way the packaging system user can plug in his own implementation everywhere. Any ideas, comments? Anyone out there who wants to join and help implementing this idea? Marc

9 29

Cabal bug, times two and a half
by Bryan O'Sullivan 26 Jan '07

26 Jan '07

I tried reporting a Cabal bug via Trac, but I can't log in as guest/haskell. Alas. The bug is that "runhaskell Setup.hs --enable-library-profiling" doesn't imply -auto-all with ghc, so the profiled library contains only manual cost centres - in other words, it never shows up in profile output. The second bug is that the only way I can find to override or add compiler flags is to edit a .cabal file by hand. This makes it scarily easy to capture unintended flags when committing changes :-( <b

4 5

cabal-make almost ready
by Conal Elliott 25 Jan '07

25 Jan '07

I've been working on some haddock-related Cabal tweaks and a "make" include file called "cabal-make", which manages syntax coloring (vis hscolour) with links from the haddock docs, web-based links to other libraries, and wiki-based user comments. It's ready to release for others' use except for one problem (as mentioned below). The --haddock-args flag ends up turning my forward slashes into backslashes (on my WinXP machine), so all of the web links are broken. I'd appreciate suggestions about this problem. You can find an example doc generated by cabal-make (a previous implementation that didn't quite fit cabal) at http://darcs.haskell.org/packages/TV/doc/html/Interface-TV-Output.html . Suggestions welcome. - Conal ---------- Forwarded message ---------- From: Conal Elliott <conal(a)conal.net> Date: Jan 19, 2007 5:18 PM Subject: Re: [Conal Elliott] Re: getting cabal to pass more info to haddock To: Isaac Jones <ijones(a)syntaxpolice.org> Cc: cabal-devel <cabal-devel(a)haskell.org> Hi Isaac. Now I see why the patch file was empty. And after some head-scratching about your note below, I'm glad the patch was empty. I hadn't noticed the --xxx-args flags for configure, and instead added a new haddock flag. Giving a flag to configure makes a lot more sense. So now I have just a new pair of flags enable-use-packages & disable-use-packages, which control whether haddock gets automatically-generated --use-package flags. My makefile are now performing this sort of incantation: ./setup configure --disable-use-packages --haddock-args="\ --read-interface=http://haskell.org/ghc/docs/latest/html/libraries/base,c:/ghc/ghc-6.6/doc/html/libraries/base/base.haddock \ --read-interface=http://haskell.org/ghc/docs/latest/html/libraries/mtl,c:/ghc/ghc-6.6/doc/html/libraries/mtl/mtl.haddock\ " The only problem is --haddock-args ends up turning my forward slashes into backslashes, so all of the web links are broken. Any advice? - Conal On 1/17/07, Isaac Jones <ijones(a)syntaxpolice.org > wrote: > > Hi Conel. Thanks for this! It sounds like the ideas from your > makefile could be used for Hackage for generating nice Haddock :) > > There is a general meachanism for adding --foo-args for each Program > that cabal knows about; can you use this meachanism to add --foo-arg > as well, instead of special-casing for haddock? > > If you do that, can you make the help output not suck? Currently it > does something like this: > > --ar-args=ARGS give the args to ar > --haddock-args=ARGS give the args to haddock > --ld-args=ARGS give the args to ld > --pfesetup-args=ARGS give the args to pfesetup > --ranlib-args=ARGS give the args to ranlib > --runghc-args=ARGS give the args to runghc > --runhugs-args=ARGS give the args to runhugs > --tar-args=ARGS give the args to tar > > it would be nice to concerve lines with sometthing like this: > > --ar-arg=ARG --ar-args=ARGS give the arg or args to ar > --haddock-arg=ARG --haddock-args=ARGS give the arg or args to haddock > etc > > The patch you sent seemed like an empty file to me. Maybe I'm just > being nihilistic ;) > > peace, > > isaac >

2 3

debugging support - multidimensional package selection - excursion
by Marc Weber 22 Jan '07

22 Jan '07

If we want to add debugging support consider a packagetree like this: a - b ( depends on b and c, c on d and e) | + - c - d | + - e its obvious if I want to have a profiling lib a I need b..e compiled with -prof, too But if I want to build it with debugging messages what about b,c,d,e They might have been compiled with debugging support but don't have to. Consider the scenario a,c,d beeing compiled as debugging, but I'm also working on another project which doesn't need c as debugging. This would mean I need two versions of c (with debugging enabled and disabled) -> naming conflict.. This could be solved by introducing aliases. eg ./cabal-install d as d-debug --enable-debug ./cabal-install c as c-debug --enable-debug --with d-debug as d ./cabal-install a --with c-debug as c and I would be done This way you can even install different developement versions of your libraries .. (sure testing should be done with HUnit or qpuickcheck not with final applications ..) Of course this is only useful for testing not for distribution ... I don't think this would make things much more complicated but would make the system much more flexible .. Wait.. This would mean: you have a package id and you have flags to select the right version a flag is a) version b) configure options such as profile, debug, use lib a instead of b, ... But this would mean when deciding which libraries to install by default: instance Default Stability -- stable wins instance Default Version -- greater wins instance Default Debug -- no debug wins instance Default Profiling -- no profiling wins if not specified else. This leads me to the question: Is it enough to identify a package by (name/id) and version? I think a more dimensional way would be useful Thus adding another dimension (os / instance Default Cross-Compilation-Target -- defaults to no cross-compilation an easy extension.. And this would make it easy to manage libs for your os, that of your neighbour, your microcontroller, .... Of course ghc-pkg list will no longer show Lib (version=2.0, debug=on, profiling=on, target-architecture=x64) rather than Lib-2.0 Some of those flags would be backtracking (architecture, profiling) others not (debug = on) Fortunately you don't have the design of ghc to test this as you can use aliases .. Any comments? Is this all nonsense ? Marc

2 1

Hackage plan
by Simon Marlow 19 Jan '07

19 Jan '07

While at the Hackathon, Björn, Ross, Ian, myself and others collected some ideas for directions in which Hackage (the web interface primarily, as opposed to cabal-install) should develop. I put everything in this wiki page: http://hackage.haskell.org/trac/hackage/wiki/HackageToDo It's quite rough, but I think it's a good starting point. I suggest we do some more brainstorming and flesh out that page, and then extract a "plan" for how to proceed. Of course the plan shouldn't be single threaded - there will be tasks that can be tackled independently, but there will necessarily be dependencies. For example there are lots of things that can't be done until we have automatic package building of some kind. We should have some milestones, focussed towards getting to a point that the system is usable quickly, and adding the bells & whistles later. First off we have two web interfaces: Ross's and Lemmih's. Ross's lets you upload. In due course having multiple web interfaces is certainly a possibility, but for now we need to focus our limited efforts in one place. I suggest Ross's inteface, being the closest to being usable, is the right place to start. Ross - is it possible to write some simple instructions describing how to set up the web interface on a local machine for development/testing? Cheers, Simon

5 4

darcs patch: Add preliminary support for haddock-ghc (and 1 more)
by davve＠dtek.chalmers.se 17 Jan '07

17 Jan '07

Fri Sep 15 21:29:49 CEST 2006 davve(a)dtek.chalmers.se * Add preliminary support for haddock-ghc Fri Jan 5 22:22:24 CET 2007 davve(a)dtek.chalmers.se * Add -D__HADDOCK__ to haddock-ghc

3 2

Re: haddock suggestion -- %{FILE}
by Conal Elliott 17 Jan '07

17 Jan '07

I did get working again by commenting out the "-optP-P" that gets passed to Haddock. Now I want to eliminate my local mod. I could easily add a another Cabal Haddock flag that says to omit the -optP-P, but I prefer the solution of checking the Haddock version number, since it would always do the right thing with no intervention. Can anyone give me hints about how to do the version check? - Conal On 1/9/07, Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> wrote: > > On Tue, 2007-01-09 at 09:32 -0800, Conal Elliott wrote: > > The only pre-processing is what's caused by using the cabal directive > > "Extensions: CPP". > > > Fiddling with flags, I see that -optP-P is the culprit. Removing it: > > > > bash-3.2$ ghc -E -cpp -o z src/Graphics/UI/TV/Input.hs > > -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH > > -Di386_HOST_ARCH -D__GLASGOW_HASKELL__=606 -D__HADDOCK__; head -3 z > > # 1 "src/Graphics/UI/TV/Input.hs" > > # 1 "<built-in>" > > # 1 "<command line>" > > bash-3.2$ > > > Any ideas? - Conal > > So for a quick hack, modify Cabal to unconditionally omit -optP-P and > see if that makes all your links come out right. > > Probably the right thing to do however is to have Cabal use the -optP-P > option only when we're using haddock-0.7 or older (otherwise haddock-0.7 > users will get a lexical error when haddock encounters the C line > pragmas). > > I think at the moment Cabal doesn't check haddock's version number at > all. So that's something to look at if you or anyone else want to come > up with a patch for this. > > > Duncan > >

2 1

new Darcs-Repository field?
by Ross Paterson 15 Jan '07

15 Jan '07

Björn Bringert suggested that the Hackage page for a package should include a link to the Darcs repo (if any, but who uses anything else?) and maybe some darcs integration such as changelogs and the like. To make this work, we'd need a URL-valued Darcs-Repository field in the package description.

6 5

ghc requesting package version 1.1.7 but 0.1.7 is installed ?
by Marc Weber 15 Jan '07

15 Jan '07

$ ghc -o setup --make -package Cabal-0.1.7 setup.hs Linking setup ... ghc-6.5.20060917: unknown package: Cabal-1.1.7 I don't understand this. I've substituted Version 1.1.7 by 0.1.7 to get a low version which won't be used unless requested. This is the only Cabal package beeing installed. $ ghc-pkg describe Cabal shows name: Cabal version: 0.1.7 license: BSD3 ... Why is ghc requesting still 1.1.7? set | grep 1.1.7 doesn't list any interesting environment variable except of pwd and OLDPWD The Cabal which has been destributed with my ghc is verison 1.1.5.9.2 thus can't be the problem. Any suggestion is appreciated. Marc

2 1

Using Cabal for dependancies
by Neil Mitchell 15 Jan '07

15 Jan '07

Hi, The Yhc compiler depends on an increasingly large number of Cabal packages - mtl and FilePath at the moment, but soon thats likely to increase by at least 3. Cabal is not yet mature enough to compile Yhc, and fitting in a compile of bits with Cabal will be quite hard because of the existing complexity in Scons. So what we'd really like to do is be able to call "cabal check-its-installed FilePath", which would return an appropriate exit code. If it wasn't installed then a darcs get, followed by a "cabal install-it-please" would be very handy. Does cabal-install provide the necessary bits for this? What is the result of installing a package that is already installed? How long til this kind of solution will be widely enough deployed that we can actually use it? Does anyone else have any other suggestions? Thanks Neil

2 3

Re: Multiple .cabal Files
by Henning Thielemann 13 Jan '07

13 Jan '07

Since the .installed-pkg-config and .setup-config files depend on the configure procedure and on the machine - shouldn't they be placed in 'dist', even more in a machine dependent sub-directory?

1 0

hackage projects for Hackathon
by Isaac Jones 09 Jan '07

09 Jan '07

Greetings! Many of you will be at the Hackathon tomorrow: http://www.haskell.org/haskellwiki/Hac_2007 I just did a brain-dump of what I think needs to get done to make cabal-install and hackage a reality. Much of the Hacking is already done and in good shape, but there are probably lots of little things to do, and there is work that needs to happen in order to gain adoption from the community. Here's my brain dump: http://hackage.haskell.org/trac/hackage/ticket/107 Of course, I'm not the only one with ideas, and others might have a lot of good ideas about what needs to be done. Above all, make it yours! Linked from the Hac 07 project page: http://www.haskell.org/haskellwiki/Hac_2007/Projects I'm going to try to be on IRC for some of the event, although the time of day isn't the best for me (since it starts at 2AM my time) :) peace, isaac

1 0

security/ experimental packages? authorization uncomon source locations, hackage db?
by Marc Weber 06 Jan '07

06 Jan '07

I've read the discussion about who is able to upload packages.. This is nice if you want to install most common packages.. But the packaging system is intended to save time. Thus what about I want to install an experimntal synthesizer which uses an experimental haskore interface from a person who hasn't registered his lib on hackage-db yet? In short: Would it be useful to allow speciyfing different download locations for dependencies in a cabal file? -- Lib.cabal -- depends: ExperimentalLib > 2.0 { location: http://person/haskell/ExperimentalLib.cabal } [...] This would give much more freedom .. I agree that it might be useful to "mask" those packages ... But its much more convinient to do cabal-install --allow-non-hackage-locations Lib than downloading/ installing/ updating those libs manually ? I think if you need total security you won't use this flag or use someithing like chroot (already mentioned) or user mode linux .. ;) But this issue adresses the question: What is hackage about: an automated installation system or an automated installation system + package list (centralized at hackagedb ?) Marc

1 0

where more info? comments on previous posts
by Marc Weber 06 Jan '07

06 Jan '07

Isaac showed me the Wiki. But I'm missing some pages discussing how hackage and tools should look like or pages which summarize decisions having be made on this list.. I think this missing because everything is in an early developement stage, right? What about adding some pages with summaries ? topics where I like to put my comment: 1) allow more than one atom beeing build with one cabal file? 2) configuration option, dependency handling ... a) different compilers / external dependencies b) proposal: flags my point of view c) hidden flags -> flag properties d) using availible libs e) posix os mingw cygwin detection? [4] f) build-profiles g) adding darcs-repository field to cabal h) external dependencies 1) allow more than one atom beeing build with one cabal file? ============================================================== "Cabal is the lowest-level tool for Haskell package management." I'd like to here some pro-cons about wether to allow putting libraries and executables into one cabal file: advantages multi atom cabal file: * it is one "Package" * one description/ license/ homepage field is sufficient * quote : "Configurations proposal On 10/24/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote: > > On the other hand, in Gtk2Hs I know one case where we do this. We have a > Graphics.UI.Gtk.Cairo api module that is only included if Gtk was built > against Cairo. In any case it could be faked by using cpp to just not > export anything rather than not having the module exposed at all. So > it's not clear that it's worth banning. Or maybe making it slightly > harder is worth it so that people don't get in the habit. Couldn't you split this into Gtk and Gtk-Cairo packages, where the latter is only built if Cairo is available? so it might be really useful to build more than one library using one package.. advantages single atom cabal file: * It does'nt make that much sense to me to allow different executables but only on lib. But allowing more than one lib will introduce another layer of abstraction as a cabal package is no longer the smallest unit. You need to check dependency within a cabal file and check dependencies not contained in cabal files * If you need library x you know you can find it in file x-version.cabal 2) configuration option, dependency handling ... ============================================================== a) different compilers versions ( see profile proposal below) Does it make sense to have more than one compiler version installed (eg ghc 6.4 6.5 and 6.6 ?) If so, whose task is to handle the different compilers? --with-hc-pkg=path --with-compiler=path or -wpath Would it make sense to have something like gcc/java-config of gentoo ? b) proposal: flags my point of view I'd like to see everything as flag. flags I'd like to add by default: - version - way = profiling | debug | optimized | distribution (user configurable ?) - stability (should be set by cabal readonly automatically) refering to [2] (build optimzed, profiling and debug version) and [3] (Duncan tells its intentional to not allow this) I agree. I'd like to be able to build different versions, too. That's why you have a packaging system that you don't have to all manually.. I yet have to look up how cabal does installing both profiling and default lib at the same time which was mentioned somewhere. One way to solve this is when building a profiling version append prof to its name. Thus if your lib L is build with profiling option it won't depend on parsec but on parsec-prof and won't be called L but L-prof. This way you have all you want, don't you? Cabal would have to add -prof option and add -prof to all names.. refering to [1]: Ian Lynagh: Why not permit declaration of flags insede a configuration? I can't see it why it should'nt be permitted c) hidden flags -> flag properties quote: " flag: fps_in_base dfault: available(base >= 2) " I like this idea (i had this tought too before reading this post) But I'd like to add "properties" to flags Thus what about: "hiden-flag: fps_in-base" ? This should mean the user can't modify it using configuration options.. d) using availible libs automatically refering to [http://www.haskell.org/pipermail/cabal-devel/2006-October/000230.html] ( On why 'availible' is evil) quote: "1. it often doesn't mean what you want 2. it allows auto-use deps 3. it makes life hard for distros and cabal-get 4. it makes the install order significant" comment to 1. If you have gtk and wxwidgets and you have the option to use either.. Then this would be a case I think its convinient to use the one already installed (?) But I agree that it wouldn't harm to set this option manually. So its cleaner to drop this auto-detection. Thanks for opening my eyes here! comment to 4. I agree. So what about determining library version which fits best independent of what can be found on the system, but add semething like emerge -p or emerge -va which tells you that lib xy is already installed having another version ? Thus if you have LibA-1.0 and wont to install LibB which would install LibA-2.0 on a plain new system I'd like to see dependencies to be installed: - LibA-2.0 (you already have 1.0, use -force-LibA-1.0 to use it) - ... This way installation order is not significant by default.. I've also read about binary packagers which don't like default flag values.. The same could be done here. Just print the automatically choosen flags and prompt for confirmation like this ./cabal-install LibA automacially determined dependencies: - LibB-2.0 unstable ( set by script, readonly) debug ( set by script, modifiable ) - haskell-db-2.0 (dependency of LibB) experimental ( set by script, readonly ) with-postgres : no with-mysql (set by command-line) with-Flat-DB (set by default) with-oracle : no - HSQL (dependency of haskell-db) with-postgres ( set by target haskell-db ) with-mysql (set by target haskell-db ) and optionally add configure option --no-defaults which prevents setting flags to default values Then everybody would be glad, right? e) posix os mingw cygwin detection? [4] Should os=windows be cygwin or mingw? no as os means operating system. mingw cygwin is no os but a build environment. I want to say it would be better to add another additional flag hasposix or is-mingw-build than changing os=windows to mingw/cygwin .. f) build-profiles What about build profiles? a build profile would consist of eg - compiler-flavour - compiler-version - flags (profile, debug, ..) - tools (use cpp = use c2hs = use greencard = ...) g) adding darcs-repository field to cabal If we talk about adding a darcs repo line to the cabal file it seems to me that cabal gets closer to maven which is a package management tool for java which handles * repositories * compilation * documentation * ide - integration (eclipse) * packaging * .. But there is one difference to cabal: It's sufficient to get the maven project description file if it contains information about how to get the source .. Thus: Does it make sense to distribute the cabal files with the source files? Why not add a general source-location: http://xy.z/.../source-2.3.tar.gz or source-location: darcs http://... line and the command ./setup fetch? but .. aeh this is the task of cabal-install, right? Sorry for this confusion.. I just don't understand yet why there are so many different tools and which task should be done by which tool.. h) external dependencies Some packages need foreign libraries (eg jnii Haskell-Java interface), (gtk/ wxwidgets) How to add them ??? i don't like to install some dependencies to notice that I also need C-lib xy .. Would it make sense to add support to install non-haskell libraries such as wxwidgets or sqlite as well ? Thus what about writing the system a little bit more general to also add a build profile for C-libraries? Unfortunately I've never used perl or CPAN.. ;( Does a page exist describing which features to implement form cpan? EG centralization ? CPAN seems to be mirrored and distributed all over the world. (But I might be wrong) Marc - sorry for this long mail quotes [1] ------------------------------------- Ian Lynagh igloo at earth.li Tue Oct 31 20:13:02 EST 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ----- Other bits A couple of other things occured to me. First, it should not be permitted to declare flags inside a configuration (I don't think anyone was saying otherwise, but I also don't think I saw it explicitly stated). [2] ------------------------------------- Configurations proposal Brian Smith brianlsmith at gmail.com Wed Oct 25 10:39:23 EDT 2006 On 10/24/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote: > > Hi All, > > Before the 6.6 release we had a longish discussion on how to do > configurations and their semantics and implementation complexity etc. > > I would like to re-propose the last scheme that I cam up with. I'll try > to make it a concrete proposal as well as giving some motivating > examples to give the intuition of the meaning. The only way I have really wanted to use configurations so far is to build debug, profiling, and optimized versions of a library. In order to build multiple configurations, is it going to still be the case that I have to "configure / build / install" separately for each configuration? I would like to be able to say something like "Setup.lhs configure --optimized --debug --profiled" to build all three versions at once. [3] ------------------------------------------ Duncan Coutts duncan.coutts at worc.ox.ac.uk Wed Oct 25 13:56:24 EDT 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > How can I say that I want the DEBUG version of package "bar" to depend > on the DEBUG version of package "foo."? Is this allowed? No. This is not allowed. Indeed you can't express it with the syntax. That's because we don't record which configurations were active for a package that was built. This is intentional. [4] Brian Smith brianlsmith at gmail.com Thu Oct 26 11:52:48 EDT 2006 * Previous message: Configurations proposal * Next message: Configurations proposal * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [...] I agree--I wish System.Info.os worked differently, actually. But, there are apparently some people (not me) that use Haskell on Cygwin, and they need to be able to detect it, because e.g. Posix and Readline are available on Cygwin but not Mingw. Maybe os(x) should be either "mingw" or "cygwin"? - Brian [4] ---------------------------------- Configurations proposal Duncan Coutts duncan.coutts at worc.ox.ac.uk Tue Oct 31 20:34:35 EST 2006 > flag: fps_in_base > default: available(base >= 2) > > configuration: fps_in_base > build-depends: base(>= 2) > > configuration: !fps_in_base > build-depends: base(< 2), fps > > The user would be able to shoot themselves in the foot by overidding the > fps_in_base flag such that they don't have the deps installed, but > that's their own fault. Note that the right thing will happen if they > just leave it as the default. Yeah it'd work but I don't like it. It exposes too much to the user for one thing. It's not always going to do the the right thing either. In this case you can only have one version of base installed at once, but for other libs that's not the case. So imagine I do have base-1.0 and 2.0 installed then there's no

1 0

darcs patch: Add preliminary support for haddock-ghc (and 2 more)
by davve＠dtek.chalmers.se 05 Jan '07

05 Jan '07

Fri Sep 15 21:29:49 CEST 2006 davve(a)dtek.chalmers.se * Add preliminary support for haddock-ghc Fri Dec 29 20:54:39 CET 2006 davve(a)dtek.chalmers.se * Make sure haddock-ghc really creates the output dir Sun Dec 31 00:21:16 CET 2006 davve(a)dtek.chalmers.se * Add compilerPath to Paths_<pkg>

1 0

Re: [David Waern] Re: darcs patch: Add preliminary support for haddock-ghc
by Neil Mitchell 01 Jan '07

01 Jan '07

Hi, > No, it doesn't work yet. So I turn the question around: Will GADT's and > other extensions be supported by Hoogle in the future? To some degree, yes. A GADT will probably be recorded as though it was a normal ADT for type matching purposes. It's similar with forall at the moment, they are entirely dropped for type matching purposes, but are searched. > Without such > support, how useful would it be to include Hoogle support in haddock-ghc? I would have thought quite useful, for example if you are going to hoogle something like Yampa, you'll need something which can at least ignore the GADT's. My larger concern was if haddock-ghc is going to replace haddock one day, then I'll definately want --hoogle in there. Thanks Neil

1 0