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

Add a bootstrap-haskell script, fixes #36 #40

Merged
merged 4 commits into from
Jan 7, 2019
Merged

Add a bootstrap-haskell script, fixes #36 #40

merged 4 commits into from
Jan 7, 2019

Conversation

hasufell
Copy link
Member

@hasufell hasufell commented Nov 4, 2018

No description provided.

@hasufell hasufell force-pushed the bootstrap branch 11 times, most recently from cc9064c to 6a2847e Compare November 4, 2018 14:10
@m-renaud
Copy link

m-renaud commented Nov 4, 2018

I added a PR for the script I had previously written (#41) for comparison.

@hasufell hasufell added this to the 0.0.7 milestone Nov 20, 2018
@m-renaud
Copy link

Hey! Anything I can do to help move this along? It would be great to have this ready when cabal 3.0 is released so there's a good story for the whole toolchain :)

@hasufell
Copy link
Member Author

hasufell commented Dec 1, 2018

@m-renaud please try the latest version

@hasufell hasufell force-pushed the bootstrap branch 2 times, most recently from 8c61516 to 2c7cd73 Compare December 1, 2018 06:48
@hasufell
Copy link
Member Author

hasufell commented Dec 1, 2018

travis is forever broken here and I cannot figure out how to fix it

@m-renaud
Copy link

m-renaud commented Dec 1, 2018

@hasufell tried it out just now, works great other than the "wait for input not working".

I downloaded the script to a local file and ran cat bootstrap-haskell | sh and it printed the prompt to press enter to continue, but continued along with actually waiting for input.

If I change the script to be executable (chmod +x bootstrap-haskell) and then ./bootstrap-haskell it works as expected. It looks likeread has different behaviour if its piped into sh instead of being run as a script as part of a pipeline (see this SO answer).

So, it looks like our options are either:

  1. Use the workaround provided there (3 commands, messier, -1 from me)
  2. Don't prompt, just install.

My vote would be for (2), if they're on the ghcup site they already know what it does. At the bottom we could give instructions for how to uninstall ghcup (namely, rm -rf ~/.ghcup), or we could also provide a ghcup uninstall command which does the right thing. I think for an initial version just providing instructions would be sufficient.

Also, I noticed that the script runs _edo ghcup set which just prints the usage of the command at the bottom:

Done installing, run "ghci-8.4.4" or set up your current GHC via: ghcup set 8.4.4
ghcup set
ghcup-set
Set the currently active GHC to the specified version

USAGE:
    ghcup set [FLAGS] <VERSION>

FLAGS:
    -h, --help       Prints help information

ARGS:
    <VERSION>        E.g. "8.4.3" or "8.6.1"

DISCUSSION:
    Sets the the current GHC version by creating non-versioned
    symlinks for all ghc binaries of the specified version in
    "~/.ghcup/bin/<binary>".

Was that intentional?

.travis.yml Outdated
@@ -15,16 +15,18 @@ addons:
- gcc
- git
- libgmp-dev
- libllvm5.0
# - libllvm5.0
Copy link

Choose a reason for hiding this comment

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

Any reason why these and below are commented out?

Copy link
Member Author

Choose a reason for hiding this comment

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

Any reason why these and below are commented out?

Because we don't use llvm code generator.

Copy link

Choose a reason for hiding this comment

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

Maybe I should have commented on the lines below, but llvm-5.0 and llvm-5.0-dev are both removed, and afaik at least one of those provides a linker in the environment. You mentioned in another comment that Travis is broken, I wouldn't be entirely surprised if this was why.

Copy link
Member Author

Choose a reason for hiding this comment

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

I doubt it. llvm is only used for llvm code generation. The linker is provided by binutils.

@m-renaud
Copy link

m-renaud commented Dec 1, 2018

I noticed you commented out some of the llvm deps in the travis config, what's the rationale behind that? It looks like it may be the cause of the issue.

@m-renaud
Copy link

m-renaud commented Dec 2, 2018

Also, I just realized that by running just ghcup set returns a status code of 1 meaning that cabal-install is never installed.

@hasufell
Copy link
Member Author

hasufell commented Dec 2, 2018

Also, I noticed that the script runs _edo ghcup set which just prints the usage of the command at the bottom:

That's because you are upgrading to an older version while the script is running. See what the travis.sh does.

I noticed you commented out some of the llvm deps in the travis config, what's the rationale behind that? It looks like it may be the cause of the issue.

Why do you think that? It's gold linker messup afais and GHC just picks up whatever it wants.

Also, I just realized that by running just ghcup set returns a status code of 1 meaning that cabal-install is never installed.

See above, you're upgrading to an older version while running the script. Set BOOTSTRAP_HASKELL_NO_UPGRADE=1.

@hasufell
Copy link
Member Author

hasufell commented Dec 2, 2018

If I change the script to be executable (chmod +x bootstrap-haskell) and then ./bootstrap-haskell it works as expected. It looks likeread has different behaviour if its piped into sh instead of being run as a script as part of a pipeline (see this SO answer).

Will look into it.

@m-renaud
Copy link

m-renaud commented Dec 2, 2018

Sorry, I don't think I was very clear in my previous comment, either that or I didn't follow your response.

When I pipe the bootstrap-haskell script though sh it doesn't complete successfully. It installs ghc but then fails at the next step:

...
Done installing, run "ghci-8.4.4" or set up your current GHC via: ghcup set 8.4.4
ghcup set
ghcup-set
Set the currently active GHC to the specified version

USAGE:
    ghcup set [FLAGS] <VERSION>

FLAGS:
    -h, --help       Prints help information

ARGS:
    <VERSION>        E.g. "8.4.3" or "8.6.1"

DISCUSSION:
    Sets the the current GHC version by creating non-versioned
    symlinks for all ghc binaries of the specified version in
    "~/.ghcup/bin/<binary>".

$ echo $?
2

The bootstrap-haskell script has the line _edo ghcup set which is incorrect usage, causing the script to exit early and never run _edo ghcup install-cabal or any of the other commands below it.

Shouldn't it be _edo ghcup set 8.4.4?

ghcup Outdated

FLAGS:
-h, --help Prints help information

ARGS:
<VERSION> E.g. \"8.4.3\" or \"8.6.1\"
[VERSION|TAG] E.g. \"8.4.3\" or \"8.6.1\" or
Copy link

Choose a reason for hiding this comment

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

Maybe use 8.6.2 as an example since 8.6.1 was a broken release?


_edo ghcup install

_edo ghcup set
Copy link

Choose a reason for hiding this comment

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

Replacing this by the following results in the script finishing successfully:

recommendedGhcVer=`ghcup list -t ghc | grep recommended | cut -f2`
_edo ghcup set $recommendedGhcVer

@hasufell
Copy link
Member Author

hasufell commented Dec 3, 2018

The bootstrap-haskell script has the line _edo ghcup set which is incorrect usage, causing the script to exit early and never run _edo ghcup install-cabal or any of the other commands below it.

Shouldn't it be _edo ghcup set 8.4.4?

No, the line is correct, I already explained it: You're upgrading to an older version while running the script. Set BOOTSTRAP_HASKELL_NO_UPGRADE=1 (after you've copied the script from this PR). Also see the commits of this PR.

@m-renaud
Copy link

m-renaud commented Dec 3, 2018

No, the line is correct...

Ah, yes you're right. I see where my confusion came from: I hadn't realized that there was a required change to ghcup in this PR to make ghcup set auto-discover the version to use if no arguments are passed. I had just pulled down a copy of the bootstrap script, not the updated ghcup so the ghcup that was being downloaded and used obviously didn't have this change so was erroring out. Sorry about the noise.

@hasufell
Copy link
Member Author

hasufell commented Dec 3, 2018

to make ghcup set auto-discover the version to use if no arguments are passed

Yeah, I think it's a useful feature. Also removes the need to hack around and try to source ghcup.

@hasufell
Copy link
Member Author

So, in order to merge this I would basically have to exclude this from the travis test...

@m-renaud
Copy link

I think it would be reasonable to exclude this from the Travis test initially and figure how to add it in as a follow-up.

@hasufell
Copy link
Member Author

The only issue remaining was the read thing right?

@m-renaud
Copy link

Yup, I think a reasonable solution for the first version of the script is to just do it without asking.

@hasufell
Copy link
Member Author

hasufell commented Jan 4, 2019

If I change the script to be executable (chmod +x bootstrap-haskell) and then ./bootstrap-haskell it works as expected. It looks likeread has different behaviour if its piped into sh instead of being run as a script as part of a pipeline (see this SO answer).

So, it looks like our options are either:

1. Use the workaround provided there (3 commands, messier, -1 from me)

2. Don't prompt, just install.

I explicitly read from /dev/tty now. This seems to work well. I'm not 100% sure how portable that is, but it seems to be part of posix: http://pubs.opengroup.org/onlinepubs/009696699/basedefs/xbd_chap10.html

@hasufell hasufell force-pushed the bootstrap branch 2 times, most recently from 0b57187 to 1277427 Compare January 4, 2019 04:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants