patch applied (cabal): "build-tools-extend-namespace" and 2 others

Mon Oct 5 22:58:31 PDT 2009 intractable@gmail.com
* build-tools-extend-namespace
M ./Distribution/Simple/Configure.hs -9 +27
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=2...
Wed May 4 18:41:44 PDT 2011 intractable@gmail.com
* intrapackage-deps-and-per-component-preprocessing
This patch adds intrapackage dependency resolution so that components
(libraries, exes, test suites) are build in the correct order. This mean it's
now possible to have, e.g., executables that depend on other executables defined
in the same package description: the build-tools namespace has been extended
accordingly.
Related to this change is the refactoring of the do-it-all preprocessSources
function, formerly invoked by initialBuildSteps, into a a function
preprocessComponent that is invoked when a component is being built. This lets
us use executables defined in a package to be used as a custom preprocessor when
building other components.
Finally, a number of functions now operate on values of the sum type
PackageDescription.Component rather than specifically operating on Library or
Executable and so forth.
M ./Distribution/PackageDescription.hs -11 +40
M ./Distribution/Simple/Build.hs -89 +88
M ./Distribution/Simple/Configure.hs -13 +45
M ./Distribution/Simple/Haddock.hs -94 +98
M ./Distribution/Simple/LocalBuildInfo.hs -1 +32
M ./Distribution/Simple/PreProcess.hs -66 +64
M ./Distribution/Simple/Program/Types.hs -1 +17
M ./Distribution/Simple/SrcDist.hs -5 +10
M ./Distribution/Simple/Utils.hs +1
M ./tests/suite.hs -2 +1
View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=2...
Sun May 8 12:09:44 PDT 2011 Duncan Coutts

Hi,
Wed May 4 18:41:44 PDT 2011 intractable@gmail.com * intrapackage-deps-and-per-component-preprocessing This patch adds intrapackage dependency resolution so that components (libraries, exes, test suites) are build in the correct order. This mean it's now possible to have, e.g., executables that depend on other executables defined in the same package description: the build-tools namespace has been extended accordingly.
Related to this change is the refactoring of the do-it-all preprocessSources function, formerly invoked by initialBuildSteps, into a a function preprocessComponent that is invoked when a component is being built. This lets us use executables defined in a package to be used as a custom preprocessor when building other components.
Finally, a number of functions now operate on values of the sum type PackageDescription.Component rather than specifically operating on Library or Executable and so forth.
M ./Distribution/PackageDescription.hs -11 +40 M ./Distribution/Simple/Build.hs -89 +88 M ./Distribution/Simple/Configure.hs -13 +45 M ./Distribution/Simple/Haddock.hs -94 +98 M ./Distribution/Simple/LocalBuildInfo.hs -1 +32 M ./Distribution/Simple/PreProcess.hs -66 +64 M ./Distribution/Simple/Program/Types.hs -1 +17 M ./Distribution/Simple/SrcDist.hs -5 +10 M ./Distribution/Simple/Utils.hs +1 M ./tests/suite.hs -2 +1
View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=2...
This patch seem to have broken preprocessing somehow. With it, Cabal is unable to build ghc-paths: Building ghc-paths-0.1.0.8... Preprocessing library ghc-paths-0.1.0.8... [1 of 1] Compiling GHC.Paths ( GHC/Paths.hs, dist/build/GHC/Paths.o ) GHC/Paths.hs:9:11: Not in scope: data constructor `GHC_PATHS_LIBDIR' GHC/Paths.hs:10:11: Not in scope: data constructor `GHC_PATHS_DOCDIR' GHC/Paths.hs:12:11: Not in scope: data constructor `GHC_PATHS_GHC' GHC/Paths.hs:13:11: Not in scope: data constructor `GHC_PATHS_GHC_PKG' David

On Tue, 2011-06-07 at 16:36 +0000, David Waern wrote:
Hi,
Wed May 4 18:41:44 PDT 2011 intractable@gmail.com * intrapackage-deps-and-per-component-preprocessing
This patch seem to have broken preprocessing somehow. With it, Cabal is unable to build ghc-paths:
Thanks David, and thanks for narrowing it down. Found out what it was and I've pushed a fix. (The underlying cause is that our UserHooks design is just too confusing for words and it tripped up our contributor and I didn't notice in code review). I hope it should also fix #859, but I need Johan to test that one (I can't make it build for what looks like unrelated reasons). Duncan
participants (3)
-
David Waern
-
Duncan Coutts
-
Johan Tibell