May 2009 - cabal-devel

Re: haddock-2.3.0 literate comments discarded from .lhs input
by Duncan Coutts 28 May '09

28 May '09

On Thu, 2009-05-28 at 11:16 +0100, Claus Reinke wrote: > >> > How about this: a way to specify paths in the package registration info that > >> > are relative to the location of the package db they are in. > >> ahem. That sounds like a backwards step, being dependent on two > >> locations instead of one. > > I don't follow this. Which two? > > package db + package path: in the current system, you only have to > update the package db if you move a package that isn't installed under > the GHC tree; in your suggestion, you also have to update it if you move > the package db/GHC itself while having non-core packages installed > outside the GHC tree. But if you're registering global packages that are installed outside of the GHC tree then you wouldn't register them using relative paths. I'm not saying everything must use relative paths. > >> With your variant, just about any change would need updating. > > I must be missing something. If you move package.conf and the packages > > in one go, then nothing needs changing as far as I can see. > > You seem to be assuming that everything is under a common root? Well it is on Windows which is the main case where people want relocatable installations. If we wanted relocatable installations on Unix then it'd all have to be under one root too, eg /opt/whatever. > That isn't the case for most unixes (different locations for bin/ doc/ > lib/ .., docs installed or not), and even on windows, it stopped being > the case with cabal insisting on 'Program Files/Haskell/...' as the > default install. Sure, extra packages should not be installed in the ghc tree and so those should not use paths relative to the ghc location. > Since ghc traditionally installs into 'c:/ghc/ghc-<version>' > (on my system, at least, but I think that no-spaces-location was > suggested by one of the GHC installers originally, and spaces in > tool paths still confuse the GHC build system), I have two locations. > > If I move GHC, nothing needs changing. If I move packages that > didn't come with GHC, package.db needs updating. If the packages > had been registered wrt to a $cabaltopdir, no changes would be > needed in either case. For some reason I really dislike the idea that we make up specific vars like $cabaltopdir for specific purposes. Perhaps that's just me. I want a general solution, not something that forces everyone to adopt conventions like installing everything in ~/.cabal/. That's just a sensible default, but the user rightly has full control over --prefix, --libdir etc etc. > In your suggestion, if I move GHC but not the packages, package.db > needs updating, No it does not. That would only be the case if you always registered things relative to ghc, but that'd be silly for things not actually installed in the ghc install tree. > if I move the packages but not GHC, package.dg needs updating, only if > I move both, and by the same relative path, no update is needed. Are you suggesting that we need to be able to move core libs that are distributed with ghc, independently of where the ghc binary is? > >> Assuming that the parts are independently located by whatever the OS > >> packaging conventions say, and can be independently relocated > >> otherwise, it seems simpler to continue with the variable scheme, but > >> with improved support and documentation for it. > > > > My suggestion seems very simple! I'm clearly missing some problem which > > you can see. > > > > To be clear, here's what I'm imagining: > > > > blah/package.conf > > blah/lib/foo-1.0/libfoo-1.0.a > > That is everything under one tree, right? Not necessarily. For the things in the same tree it'd be sensible to use relative paths. For things not in the same tree it'd be sensible to use absolute paths. This scheme also allows other sets of relocatable packages, so long as ghc gets told where to find the package.conf. > And since package.conf is GHC's register, GHC would have to be in that > tree as well. For core packages shipped with ghc/hp, yes. > > and package.conf would contain foo-1.0 with paths looking like > > "$dbdir/lib/foo-1.0". That is, we interpret $dbdir (or whatever var name > > we agree on) as being "blah/" because that's the dir containing the db. > > > > So crucially, it doesn't really matter where ghc.exe is. Assuming ghc > > can find the package conf then it can find all the files. So it'd let > > you create multiple relocatable package collections. If the primary > > package db is kept relative to ghc (eg in ghc's topdir) then the whole > > ghc installation including libs is relocatable > > That is what GHC did on windows before cabal changed the package > locations away to a path that neither GHC nor its build tools can use. Do you mean installing binaries in C:\Program Files\Haskell\bin by default? That decision was made by the Windows users. It's true that the GHC build system cannot work in a directory containing spaces, and that's probably too hard to fix. However using tools (eg happy, alex) that are in a dir containing spaces should not be nearly so hard to fix. > Is that even possible on unix systems, with their various packaging and > location traditions? I'm not sure what you're referring to. > And if Simon ever makes that breakthrough of binary compatibility > at least between minor GHC versions, we can't have the libraries in > the GHC directories, as they'd be shared between several GHCs. I've never suggested they should be. Only things distributed with ghc/hp should be together in one relocatable tree. Everything else the user installs should go in the appropriate locations. Duncan

1 0

patch applied (cabal): Use componentPackageDeps, remove packageDeps, add externalPackageDeps
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 15:50:16 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Use componentPackageDeps, remove packageDeps, add externalPackageDeps So now when building, we actually use per-component set of package deps. There's no actual change in behaviour yet as we're still setting each of the componentPackageDeps to the union of all the package deps. M ./Distribution/Simple/Build/Macros.hs -2 +2 M ./Distribution/Simple/Configure.hs -1 M ./Distribution/Simple/GHC.hs -19 +22 M ./Distribution/Simple/Haddock.hs -11 +17 M ./Distribution/Simple/JHC.hs -7 +8 M ./Distribution/Simple/LHC.hs -19 +22 M ./Distribution/Simple/LocalBuildInfo.hs -11 +18 M ./Distribution/Simple/NHC.hs -4 +4 M ./Distribution/Simple/Register.hs -4 +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527225016-adfee-c066f23b…

1 0

patch applied (cabal): Pass ComponentLocalBuildInfo to the buildLib/Exe
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 14:07:31 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Pass ComponentLocalBuildInfo to the buildLib/Exe Not yet used M ./Distribution/Simple/Build.hs -19 +26 M ./Distribution/Simple/GHC.hs -5 +8 M ./Distribution/Simple/Hugs.hs -5 +8 M ./Distribution/Simple/JHC.hs -5 +7 M ./Distribution/Simple/LHC.hs -5 +8 M ./Distribution/Simple/NHC.hs -5 +7 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527210731-adfee-b06c3099…

1 0

patch applied (cabal): Simplify writeInstalledConfig slightly
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 13:47:55 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Simplify writeInstalledConfig slightly M ./Distribution/Simple/Register.hs -7 +5 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527204755-adfee-1cd72bec…

1 0

patch applied (cabal): No need to drop dist/installed-pkg-config after every build
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 13:45:00 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * No need to drop dist/installed-pkg-config after every build We generate this file if necessary when registering. M ./Distribution/Simple.hs -8 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527204500-adfee-b49c5491…

1 0

patch applied (cabal): Make absoluteInstallDirs only take the package id
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 13:31:12 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Make absoluteInstallDirs only take the package id It doesn't need the entire PackageDescription M ./Distribution/Simple/Build/PathsModule.hs -3 +3 M ./Distribution/Simple/Configure.hs -2 +2 M ./Distribution/Simple/Install.hs -4 +4 M ./Distribution/Simple/LocalBuildInfo.hs -10 +10 M ./Distribution/Simple/Register.hs -4 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527203112-adfee-f1945894…

1 0

patch applied (cabal): Rejig calls to per-compiler build functions
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 12:51:46 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Rejig calls to per-compiler build functions So it's now a bit clearer what is going on in the generic build code Also shift info calls up to generic code M ./Distribution/Simple/Build.hs -13 +27 M ./Distribution/Simple/GHC.hs -4 M ./Distribution/Simple/JHC.hs -3 +1 M ./Distribution/Simple/LHC.hs -4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527195146-adfee-a2d0e477…

1 0

patch applied (cabal): Split nhc and hugs's build action into buildLib and buildExe
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 12:42:06 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Split nhc and hugs's build action into buildLib and buildExe M ./Distribution/Simple/Build.hs -2 +4 M ./Distribution/Simple/Hugs.hs -109 +123 M ./Distribution/Simple/NHC.hs -80 +83 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527194206-adfee-685e1454…

1 0

patch applied (cabal): Split JHC's build into buildLib and buildExe
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 12:20:36 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Split JHC's build into buildLib and buildExe M ./Distribution/Simple/Build.hs -1 +2 M ./Distribution/Simple/JHC.hs -24 +28 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527192036-adfee-c746ced8…

1 0

patch applied (cabal): Sync LHC module from GHC module
by Duncan Coutts 27 May '09

27 May '09

Wed May 27 12:16:15 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Sync LHC module from GHC module M ./Distribution/Simple/Build.hs -3 +4 M ./Distribution/Simple/LHC.hs -196 +200 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090527191615-adfee-603337c7…

1 0