-
Notifications
You must be signed in to change notification settings - Fork 701
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
WIP: Rewrite bootstrap #6719
WIP: Rewrite bootstrap #6719
Conversation
a37a342
to
08cb976
Compare
ec42627
to
513356f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good start.
At the end I'd keep generating of bootstrap-deps.json
and "runner" as separate scripts, but that can be done later. (I'd also rewrite the generator later in Haskell, there is e.g .cabal-plan
library etc.)
cabal-install/bootstrap.py
Outdated
from typing import Set, Optional, Dict, List, Tuple, \ | ||
NewType, BinaryIO, NamedTuple | ||
|
||
ghc_path = Path('ghc') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of problems with old bootstrap was that we were somewhat sensitive to the ghc
version used. We should use ghc --version
info.
Or better we should parse ghc --info
and find ghc-pkg
using LibDir
, as perfectly boostrapping ghc should be configurable (i.e. we wouldn't need to rely on PATH).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or better we should parse
ghc --info
and findghc-pkg
usingLibDir
, as perfectly boostrapping ghc should be configurable (i.e. we wouldn't need to rely on PATH).
This suggestion seems very fragile to me. The ghc-pkg
wrapper in bin/
arranges to pass --global-package-db
to the ghc-pkg
executable in LibDir
. We would need to duplicate this logic if we were to use the LibDir
executable directly.
Moreover, on some platforms (e.g. NixOS) the executable in PATH
is actually a distribution-provided wrapper which sets up other state. IMHO we shouldn't start poking around in LibDir
. If anything we should just look for a ghc-pkg
in the same directory as we found the ghc
executable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It actually turns out the that the --global-package-db
flag that I noted above is added by the NixOS wrapper. Nevertheless, the point stands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sad to learn about this.
The simple heuristics don't work:
% $(dirname $(which ghc-8.10.1))/ghc-pkg --version
GHC package manager version 8.8.3
we have better heuristics for these, but they don't work if suffix is arbitrary. I'd rather not to use heuristics, and for special (and I consider NixOS special) situations users would rather required to be explict.
NixOS probably uses wrapper because --global-package-db
because they fake global installs, not actually do that. That doesn't affect bootstrap.sh because it doesn't use "extras".
|
Not necessarily. We could decide that we want to include a bootstrap dependencies description for a couple of supported bootstrap compilers in the repository. I'll leave this decision to you and @phadej. |
513356f
to
c2c6f8c
Compare
We still need to sort out if/how we want to package the build dependency sets in the tree. |
ea93f10
to
0b4a20a
Compare
I cannot tell what the meta check is worried about. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a step into right direction.
Addressed comments. @phadej, how would you like to handle merging this? Should I drop the |
The plan: A JSON file (generated with bootstrap.py --extract-plan) containing dependency and source information is built from plan.json. This is then used to fetch and build the bootstrapping dependencies. Since this is only to be used for bootstrapping on new architectures, we advise the users to only use the resulting cabal-install executable to build a proper cabal-install.
f79f951
to
12ab32d
Compare
Ping @phadej. |
@phadej, I'd love to use this for building the OpenBSD port. It would be awesome to merge before 3.4. |
Quick observation: after rebasing the |
I'm looking at this.
Both are easy enough to fix, and I'll do that. |
Continued in #6979 |
Given I've complained about this in the past, I felt compelled to pick up #6700. This currently requires a reasonably modern Python (Python 3.5 or newer) but if this is a problem we could likely relax this to Python >= 3.2.
The idea
A JSON file (generated with
bootstrap.py --extract-plan
) containing dependency and source information is built fromplan.json
. This is then used to fetch and build the bootstrapping dependencies. Since this is only to be used for bootstrapping on new architectures, we advise the users to only use the resultingcabal-install
executable to build a propercabal-install
.To-do
plan.json
bootstrap-deps.json
; should it be in the repository?