- cabal-devel - Haskell.org

[Fwd: Re: [Haskell] Cabal, Haddock, and the location of documentation]
by Duncan Coutts 09 Jul '07

09 Jul '07

-------- Forwarded Message -------- > From: Matthias Kilian <kili(a)outback.escape.de> > To: Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> > Cc: cabal-devel(a)haskell.org > Subject: Re: [Haskell] Cabal, Haddock, and the location of > documentation > Date: Sun, 8 Jul 2007 22:23:25 +0200 > > On Sun, Jul 08, 2007 at 06:22:43PM +0100, Duncan Coutts wrote: > > I think it'd be perfectly reasonable to follow the lead of autoconf here > > and have slightly finer grained control with respect to the kinds of > > files we're installing. Autoconf distinguishes docs (and various kinds > > of docs, html, ps, pdf, man etc) from the generic datadir. > > > > So yes, if you want to extend cabal in this direction I'm happy to > > review patches. > > Ok, I'll give it a try, but it'll take a while (a week or two). > First I've to get all the OpenBSD ports updated (including horrible > workarounds for the missing docdir option). Everything else would > be maintainance hell for me ;-) > > Anyway, what are the requirements/whishes? > > - Just docdir, maybe htmlsubdir or haddocksubdir > - Or docdir and separate htmldir / haddockdir > - Something more flexible > > Ciao, > Kili

1 0

Does hjs depend on regex-base ?
by Marc Weber 09 Jul '07

09 Jul '07

hjs -> regex-compat -> regex-base ghc-6.6.1: unknown package: regex-base-0.91 (dependency of regex-compat-0.90) Preprocessing executables for hjs-0.2... Obviously you can't compile regex-compat without regex-base. Thus you can/should assume that you have also regex-base installed if you find regex-compat, right? Is this intentionally? Mmmh This means I must iterate over the whole dependency tree to collect them all. Marc Weber

2 1

Re: [Haskell] Cabal, Haddock, and the location of documentation
by Duncan Coutts 09 Jul '07

09 Jul '07

Moving discussion to the cabal-devel(a)haskell.org list... On Sun, 2007-07-08 at 19:08 +0200, Matthias Kilian wrote: > Hi, > > probably a PEBCAK, but working on updating all our Haskell-related > OpenBSD ports, I've currently the problem, that, e.g. for Crypto > the Haddock-generated documentation doesn't gets installed where I > want it installed ;-) [...] > Is this configurable at Cabal/Haddock runtime? I'd try to play > with --datadir, but this appears a little bit dangerous as a general > approach, since some packages my actually come with real data, which > should *not* go into $prefix/share/doc, of course. Currently the docs do just use --datadir= and --datasubdir= . > Or do I have to patch Cabal? If so, what about adding just another > FilePath like docdir to Distribution.SimpleLocalBuildInfo and use > it for the documentation? I think it'd be perfectly reasonable to follow the lead of autoconf here and have slightly finer grained control with respect to the kinds of files we're installing. Autoconf distinguishes docs (and various kinds of docs, html, ps, pdf, man etc) from the generic datadir. So yes, if you want to extend cabal in this direction I'm happy to review patches. Duncan

2 1

Need a username for Hackage
by Marc Weber 08 Jul '07

08 Jul '07

Hi Ross. (CC cabal-devel) I'm adding all packages from hackage to the nix distribution system. However I'v noticed some small issues. (eg Renaming FilePath -> filepath) Should I fix the issues in nix only or should I fix the packages on hackage? If so I would need an account on hackage. Marc Weber

4 7

Re: Re[2]: [Haskell-cafe] Binary serialization, was Re: Abstraction leak
by Duncan Coutts 07 Jul '07

07 Jul '07

On Fri, 2007-07-06 at 08:26 +0200, Ketil Malde wrote: > On Thu, 2007-07-05 at 18:08 +0100, Duncan Coutts wrote: > > > > > - Found that on hackage, downloaded and built OK. Lots of scary > > > > warnings about happy, greencard etc, not being found during configure, > > > > but let's go on. > > > > I've complained about these before, although I don't think anyone > > > considered doing anything about it. > > > We know what needs to change, but it's not a trivial change. > > > The problem is that currently .cabal files to not specify what build > > tools they need, > > A possible stop-gap might be to only report the build tools that were > actually found? The way it is now, it looks too much like an error > message. Mmm, good point. Perhaps we could just change the verbosity of that message for now, so that it doesn't appear at the default verbosity level. Duncan

1 0

Should HEAD of Cabal be depending on the new library world order?
by Bryan O'Sullivan 06 Jul '07

06 Jul '07

Hi, all - I just pulled a backlog of changes from the HEAD of the Cabal repo, and now I can no longer build Cabal with ghc 6.6.1. This makes working with it while running GHC 6.6.1 a bit awkward, so my poor cabal-rpm tool is stuck in a limbo where I can't easily build it except against a manually hacked copy of Cabal. Is there any chance that we could bless some revision of Cabal that will compile with GHC 6.6.1, give it a name, and then go back and resplit things in preparation for future greatness? If people see some value in this, I can do the necessary legwork. <b

3 2

RFC: Cabal-Configurations patch(es)
by Thomas Schilling 29 Jun '07

29 Jun '07

Hi, you just received a longish patch bundle, that together implement Cabal configurations. I realized too late that there's a way to combine this mail with the actual patch, so consider this an addendum. The implementation can read all old Cabal-files (and should do the same), but unfortunately, I had to change the interface of the confHook function, which I assume will break some setup files. The documentation states, that you shouldn't depend on that interface, but then again do people have to use them if they have special requirements. The most important change is, that Cabal files are now parsed to 'PreparedPackageDescription' which requires a run of 'finalizePackageDescription' to get to the actual 'PackageDescription'. This resolving process is potentially very slow (exponential in the number of flags), especially if there is no possible flag assignment. I plan to correct this by adding some minimum SAT solving capabilities, which will however still be exponential in the worst case. For now, the current implementation should be sufficient, though. My testing is far from exhaustive, as I haven't yet found a good way of setting up a suitable test environment without endangering to break my current setup. I am setting up a ghc-HEAD installation, but there is currently a build error stopping me from it. Incidentally, Cabal itself now needs configurations to build with ghc-head as well as ghc-6.6.1. That said, I'd like to ask you to review the patches and possibly also test it on your projects. A preliminary HOWTO is at: http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations Thanks, / Thomas

2 2

darcs patch: Regenerate GHCMakefile.hs
by Clemens Fruhwirth 29 Jun '07

29 Jun '07

Fri Jun 29 12:58:56 CEST 2007 Clemens Fruhwirth <clemens(a)endorphin.org> * Regenerate GHCMakefile.hs

1 0

darcs patch: Add dynamic way for building via GHC Makefiles
by Clemens Fruhwirth 29 Jun '07

29 Jun '07

Fri Jun 29 12:58:40 CEST 2007 Clemens Fruhwirth <clemens(a)endorphin.org> * Add dynamic way for building via GHC Makefiles

1 0

darcs patch: For shared libs compile .hs and .c files with -fPIC, a...
by Clemens Fruhwirth 29 Jun '07

29 Jun '07

Thu Jun 28 13:49:51 CEST 2007 Clemens Fruhwirth <clemens(a)endorphin.org> * For shared libs compile .hs and .c files with -fPIC, and link with new ghc -shared option.

1 0