Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #3483, set HASKELL_DIST_DIR #3697

Merged
merged 4 commits into from
Aug 18, 2016
Merged

Conversation

ezyang
Copy link
Contributor

@ezyang ezyang commented Aug 16, 2016

But first things first; need unsetEnv to implement withEnv to implement same-process environment change.

See https://ghc.haskell.org/trac/ghc/ticket/12494; we cargo-culted
some incorrect code from base. Lift the restriction.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
@mention-bot
Copy link

@ezyang, thanks for your PR! By analyzing the annotation information on this pull request, we identified @ttuegel, @23Skidoo and @phadej to be potential reviewers

@23Skidoo
Copy link
Member

LGTM so far.

@ezyang ezyang force-pushed the pr/env-haskell-dist-dir branch from 0351e30 to c1c01bc Compare August 16, 2016 10:36
@@ -334,7 +335,8 @@ selfExecSetupMethod verbosity options _pkg bt mkargs = do

searchpath <- programSearchPathAsPATHVar
(getProgramSearchPath (useProgramConfig options))
env <- getEffectiveEnvironment [("PATH", Just searchpath)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this to work properly with the self-exec setup method we probably also want HASKELL_DIST_DIR=/foo/bar cabal $CMD to behave identically to cabal $CMD --builddir=/foo/bar.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@23Skidoo I understand not—I'd have expected the outer cabal $CMD (say install) to override HASKELL_DIST_DIR (as it does); the change should be behavior-preserving, other than the extra variable in the environment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I don't understand @23Skidoo's comment either.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, his idea would make sense if we wanted to propagate HASKELL_DIST_DIR automatically to any sub-cabal process—not what this PR is about.
In scenarios that do need that for whatever reason (assuming they exist, and maybe they do), scripts can/should use --builddir=$HASKELL_DIST_DIR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I retract my comment. For some reason I thought that act-as-setup --builddir is a thing and was worried about potential inconsistencies.

@ezyang
Copy link
Contributor Author

ezyang commented Aug 16, 2016

For people who want this PR, would it be possible for you to (1) test and see if it works for you, (2) help add some tests for this PR? (Probably integration-tests) Thanks.

@@ -304,7 +304,8 @@ internalSetupMethod verbosity options _ bt mkargs = do
info verbosity $ "Using internal setup method with build-type " ++ show bt
++ " and args:\n " ++ show args
inDir (useWorkingDir options) $
buildTypeAction bt args
withEnv "HASKELL_DIST_DIR" (useDistPref options) $
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add a comment here that in the case of the internal setup method we're doing this for the sake of build-types Configure and Make, since the Cabal library code does not care about HASKELL_DIST_DIR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're doing ./Setup test the test script might care too. So really it needs to apply in all cases.

@23Skidoo
Copy link
Member

LGTM.

@ezyang ezyang force-pushed the pr/env-haskell-dist-dir branch from 825f48e to 44fc26b Compare August 17, 2016 03:06
ezyang added 3 commits August 16, 2016 21:50
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
@ezyang ezyang force-pushed the pr/env-haskell-dist-dir branch from 44fc26b to a0efec0 Compare August 17, 2016 04:50
@ezyang ezyang merged commit 9cb6a99 into haskell:master Aug 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants