cabal new-build & {alex,happy}
#4009
Milestone
Comments
|
Turns out, there's a very similiar problem when using legacy sandboxes: haskell/alex#54 |
|
The following partial revert of 8dc39db was suggested by @dcoutts: diff --git a/cabal-install/Distribution/Client/ProjectBuilding.hs b/cabal-install/Distribution/Client/ProjectBuilding.hs
index 0f3ae1b..0a69c43 100644
--- a/cabal-install/Distribution/Client/ProjectBuilding.hs
+++ b/cabal-install/Distribution/Client/ProjectBuilding.hs
@@ -749,11 +749,11 @@ withTarballLocalDirectory verbosity distDirLayout@DistDirLayout{..}
-- builddir under the tarball src dir to keep path name lengths down.
BuildAndInstall ->
let tmpdir = distTempDirectory in
- withTempDirectory verbosity tmpdir "src" $ \unpackdir ->
- withTempDirectory verbosity tmpdir "build" $ \builddir -> do
+ withTempDirectory verbosity tmpdir "src" $ \unpackdir -> do
unpackPackageTarball verbosity tarball unpackdir
pkgid pkgTextOverride
let srcdir = unpackdir </> display pkgid
+ builddir = srcdir </> "dist"
buildPkg srcdir builddirUPDATE: I've tested the patch above improves the situation |
hvr
added a commit
that referenced
this issue
Oct 20, 2016
Packages like `alex` include pre-generated lexer/parser source in their source tarball as e.g. dist/build/alex/alex-tmp/Scan.hs dist/build/alex/alex-tmp/Parser.hs to avoid having to have alex already installed before building alex... Unfortunately, 8dc39db broke packages relying on this accidental feature by changing where the distdir points to. This patch partly reverts that commit and therefore addresses the regression aspect of #4009.
hvr
added a commit
that referenced
this issue
Oct 21, 2016
Packages like `alex` include pre-generated lexer/parser source
in their source tarball as e.g.
dist/build/alex/alex-tmp/Scan.hs
dist/build/alex/alex-tmp/Parser.hs
to avoid having to have `alex` already installed before building
`alex`...
Unfortunately, 8dc39db broke
packages relying on this accidental feature by changing where the
distdir points to. This patch partly reverts that commit and
therefore addresses the regression aspect of #4009.
This fix was suggested by @dcoutts
|
OK fixed now. |
|
@ezyang the |
|
I can't easily test this but I'll take your word for it. Why doesn't it work for |
|
Just tested and this appears very much resolved at this point. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
UPDATE: Partially (specifically for the case when
alex/happyare to be installed into the nix store because they were requested viabuild-tools), this turns out to be a regression introduced by 8dc39dbnew-buildcurrently isn't able to self-bootstraphappyandalex(which are two special cases in Haskell's ecosystem and for it's imho legitimate to add special logic tonew-build), and this is causing problems for thenew-buildbased Travis scripts which don't installalex/happyvia binary packages anymore:and similiarly for
alex:after adding a line
build-tools: happy == 1.19.*toalex.cabal, we get now:IMO, it ought to be possible to install
happywithout having a prior version ofhappyinstalled, and likewise possible to installalexwithout having a prioralexinstalled.And in fact,
alexincludes pre-generated.hscode in its.tar.gzfor that:and similarly
happyincludes:I think it makes sense for
alexto not specifybuild-tools: alex, and take that as a hint that there's a pre-generated.xsource bundled in the source-tarball (however, the legacy pathname./dist/build/alex/alex-tmp/Parser.hsis imho a bad choice, but we will have to support that for the sake of existingalex/happyreleases). Otoh, if a package specifiesbuild-tools: alex, I'd expect the.xfiles to be regenerated bycabal(and buildalexif needed).Maybe for the future, something interacting with the new
autogen-modulesfield would make sense here for a more principled solution./cc @ezyang
The text was updated successfully, but these errors were encountered: