- cabal-devel - Haskell.org

CPP confusion
by Duncan Coutts 16 Oct '07

16 Oct '07

All, There seems to me to be a great deal of confusion with CPP options in Haskell land. We apply the same cpp options to C code and to Haskell code, and there are other tools like pre-processors which make things even more confusing. The latest thing I've stumbled over is HsUnix.h in ghc-6.8. This header file is for defines to use when pre-processing Haskell code. It used to live in the global $GHCLIBDIR/include but now lives in the include dir for the unix package. This is probably the right thing to do, however... How do packages that want to use this include actually use it? If they #include it directly in a .hs file then it'll work since ghc -package unix adds the unix package's include dir to the search path. But what if someone needs to use it in a .hsc file? Well, then it does not work. It does not work because Cabal does not pass these include directories to hsc2hs, since we've relied on ghc to do that. But obviously that does not work for hsc2hs. As it happens the fork of hsc2hs that ghc comes bundled with uses ghc as it's C compiler, so we could in fact pass hsc2hs --cflag=-package --cflag=unix then it does work because hsc2hs ends up passing ghc -package unix and then ghc adds the unix's include dir to the search path when it goes on to call gcc to actually compile the C code. Yay, for many layers of confusion. So what is the solution? We could take advantage of the fact that we know that hsc2hs really uses ghc as it's C compiler and change the flags we pass it when we happen to be building with ghc. On the other hand this all becomes non-portable. In fact this totally relies on a package database to remember what search directories to use when pre-processing dependent packages. In other words it only has a chance of working with ghc at the moment, or nhc in future if/when it implements a package database. What to do? Short and long term suggestions please. Duncan

2 1

Re: [Haskell-cafe] Re: Proposal: register a package as providingseveral API versions
by Simon Marlow 16 Oct '07

16 Oct '07

Claus Reinke wrote: >> It could be done using the tricks that Claus just posted and I >> followed up on. You'd need a separate package for hsFoo-2 that >> specifies exactly which bits of hsFoo-3 are re-exported. Given some >> Cabal support and a little extension in GHC, this could be made >> relatively painless for the library maintainer. > > are those tricks necessary in this specific case? couldn't we > have a list/range of versions in the version: field, and let cabal > handle the details? I don't understand what you're proposing here. Surely just writing version: 1.0, 2.0 isn't enough - you need to say what the 1.0 and 2.0 APIs actually *are*, and then wouldn't that require more syntax? I don't yet see a good reason to do this in a single .cabal file instead of two separate packages. The two-package way seems to require fewer extensions to Cabal. > aside: what happens if we try to combine two modules M and N > that use the same api A, but provided by two different packages > P1 and P2? say, M was built when P1 was still around, but when > N was built, P2 had replaced P1, still supporting A, but not necessarily > with the same internal representation as used in P1. Not sure what you mean by "try to combine". A concrete example? Cheers, Simon

1 0

Re: Proposal: register a package as providing several API versions
by Simon Marlow 16 Oct '07

16 Oct '07

ChrisK wrote: > Simon Marlow wrote: >> Several good points have been raised in this thread, and while I might >> not agree with everything, I think we can all agree on the goal: things >> shouldn't break so often. > > I have another concrete proposal to avoid things breaking so often. Let us > steal from something that works: shared library versioning on unixy systems. > > On Max OS X, I note that I have, in /usr/lib: >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.2.dylib -> libcurl.3.dylib >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.3.0.0.dylib -> libcurl.3.dylib >> -rwxr-xr-x 1 root wheel 201156 Aug 17 17:14 libcurl.3.dylib >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.dylib -> libcurl.3.dylib > > The above declaratively expresses that libcurl-3.3.0 provides the version 3 API > and the version 2 API. > > This is the capability that should be added to Haskell library packages. > > Right now a library can only declare a single version number. So if I update > hsFoo from 2.1.1 to 3.0.0 then I cannot express whether or not the version 3 API > is a superset of (backward compatible with) the version 2 API. Certainly, this is something we want to support. However, there's an important difference between shared-library linking and Haskell: in Haskell, a superset of an API is not backwards-compatible, because it has the potential to cause new name clashes. > Once it is possible to have cabal register the hsFoo-3.0.0 also as hsFoo-2 it > will be easy to upgrade to hsFoo. No old programs will fail to compile. > > Who here knows enough about the ghc-pkg database to say how easy or hard this > would be? It could be done using the tricks that Claus just posted and I followed up on. You'd need a separate package for hsFoo-2 that specifies exactly which bits of hsFoo-3 are re-exported. Given some Cabal support and a little extension in GHC, this could be made relatively painless for the library maintainer. Cheers, Simon

2 1

Re: Proposal: register a package as providing several API versions
by apfelmus 16 Oct '07

16 Oct '07

Simon Marlow wrote: > The proposed policy, for the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > [..] > dependencies must specify a single x.y API version, or a range of > versions with an upper bound. What about x == 0? I mean, the intention of 0 is that 0.1, 0.2 and so on may well overthrow the API. But that's a bikeshed issue. ChrisK wrote: > The above declaratively expresses that libcurl-3.3.0 provides the version 3 API > and the version 2 API. Good idea. In the end, both proposals are based on the same observation: the dependency knows best which of its versions are compatible and which aren't. It's *not* a responsibility of the dependent package to know that. It only has to know one particular version it compiles against. So, it would just specify "I do compile with foobar 1.2" and let foobar 1.3 decide whether it's compatible with 1.2 or not. Given Simon's proposed policy, the answer would be "yes", if it were not for possible name clashes: > However, there's an important difference between shared-library > linking and Haskell: in Haskell, a superset of an API is not > backwards-compatible, because it has the potential to cause new name clashes. Solution? explicit imports? explicit module signatures with subtyping? implicit signature conversion foobar 1.3 -> foobar 1.2 on the package level? Regards, apfelmus

1 0

Re: [Hackage] #160: PatternSignatures missing in Extensions
by Hackage 16 Oct '07

16 Oct '07

#160: PatternSignatures missing in Extensions ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.6 | Platform: Linux ---------------------+------------------------------------------------------ Comment (by guest): I'ld like to add that the error message for a wrong entry under extensions is quite poor: {{{ Parse of field 'extensions' failed: }}} Christian.Maeder(a)dfki.de -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/160#comment:1> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Haskell] Re: Trying to install binary-0.4
by Simon Marlow 16 Oct '07

16 Oct '07

Claus Reinke wrote: >>> - if you provide a 'base' configuration that pulls in the stuff that >>> used to be in base, the package will work >> >> I don't know of a way to do that. The name of the package is baked >> into the object files at compile time, so you can't use the same >> compiled module in more than one package. > > i've been wrong about this before, so check before you believe,-) but > here is a hack i arrived at the last time we discussed this: > > [using time:Data.Time as a small example; ghc-6.6.1] > > 1. create, build, and install a package QTime, with default Setup.hs ... > 2. create, build, and install a package Time2, with default Setup.hs ... > 3. write and build a client module Ok, when I said above "I don't know a way to do that", I really meant there's no way to do it by modifying the package database alone, which I think is what Udo was after. Your scheme does work, and you have discovered how to make a package that re-exports modules from other packages (I made a similar discovery recently when looking into how to add support to Cabal for this). As you can see, it's rather cumbersome, in that you need an extra dummy package, and two stub modules for each module to be re-exported. One way to make this easier is to add a little extension to GHC, one that we've discussed before: module Data.Time (module Base1.Data.Time) where import "base-1.0" Data.Time as Base1.Data.Time the extension is the "base-1.0" package qualifier on the import, which GHC very nearly supports (only the syntax is missing). Now you don't need the dummy package, and only one stub module per module to be re-exported. Cabal could generate these automatically, given some appropriate syntax. Furthermore, this is better than doing something at the package level, because you're not stuck with module granularity, you can re-export just parts of a module, which is necessary if you're trying to recreate an old version of an API. I was going to propose this at some point. Comments? Cheers, Simon

1 1

Re: [Haskell-cafe] Adding GLUT package to WinHugs
by Neil Mitchell 16 Oct '07

16 Oct '07

Hi Peter, > Also typing runhugs Setup.hs configure fails with > > runhugs: Error occurred > ERROR "c:\program > files\winhugs\packages\base\Text\ParserCombinators\ReadP.hs":156 > - Syntax error in type expression (unexpected `.') This is because Cabal gets it wrong. You need to type runhugs -98 Setup configure. There is an easy fix, which is for the Cabal developers to always use the bundled ReadP rather than the library one. I talked to Duncan about this in Germany, and he said he'd fix it :-) Thanks Neil

3 3

Re: [Hackage] #155: show . readPackageDescription /= id
by Hackage 15 Oct '07

15 Oct '07

#155: show . readPackageDescription /= id ----------------------------------------+----------------------------------- Reporter: kolmodin(a)dtek.chalmers.se | Owner: nominolo Type: defect | Status: assigned Priority: normal | Milestone: Component: Cabal | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ----------------------------------------+----------------------------------- Comment (by duncan): This works now I think. Can someone check it and close this bug please. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/155#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-branches/cabal-1.2): Move ghcVerbosity function into GHC module to share code
by Duncan Coutts 15 Oct '07

15 Oct '07

Sun Oct 14 09:57:30 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Move ghcVerbosity function into GHC module to share code M ./Distribution/Simple/GHC.hs -4 +9 M ./Distribution/Simple/SetupWrapper.hs -7 +2

1 0

patch applied (cabal-branches/cabal-1.2): Pass -c (silent create) to ar when verbosity < normal.
by Duncan Coutts 15 Oct '07

15 Oct '07

Sat Oct 13 15:09:06 PDT 2007 bjorn(a)bringert.net * Pass -c (silent create) to ar when verbosity < normal. M ./Distribution/Simple/GHC.hs -2 +5

1 0