-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
gh-124932: Cross builds: Distinguish build prefix from host prefix #124933
base: main
Are you sure you want to change the base?
Conversation
…ost prefix In Emscripten and wasi builds, and presumably for other cross builds, the build file system and the host file system look different. For instance, we may want to install into `cross-build/$TARGET/lib` and then mount that as `/lib` in the host file system. `wasi.py` has to mess around with setting `PYTHONPATH` because `prefix` is set to a path from the build machine. It would simplify this if we distinguish between: * `prefix` -- the path in the build file system where we want to install the files * `host_prefix` -- the path in the host file system where getpath.c will look for the files And similarly for `exec_prefix` and `host_exec_prefix`.
I think the issue title is a bit misleading as this is only for WASI and Emscripten (which isn't officially tier 3 again yet). |
if test -z "$host_prefix"; then | ||
AS_CASE([$ac_sys_system], | ||
[Emscripten], [host_prefix=/], | ||
[WASI], [host_prefix=/], |
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 haven't tried the PR out, but won't this forcibly anchor a WASI build to mount lib
at /
?
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 presume the WASI situation is more akin to the iOS/Android case, where the runtime mount point depends on how/where the code is running, rather than knowing ahead of time that the code will be installed at a known fixed mount point?
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.
Agreed the ability to differentiate between build-time and run-time general capability would be useful in other cross-build situations (notably, iOS and Android). One Q to resolve inline about WASI support; there's also a need for a NEWS entry.
if test -z "$host_prefix"; then | ||
AS_CASE([$ac_sys_system], | ||
[Emscripten], [host_prefix=/], | ||
[WASI], [host_prefix=/], |
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 presume the WASI situation is more akin to the iOS/Android case, where the runtime mount point depends on how/where the code is running, rather than knowing ahead of time that the code will be installed at a known fixed mount point?
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
In Emscripten and wasi builds, and presumably for other cross builds, the build file system and the host file system look different. For instance, we may want to install into
cross-build/$TARGET/lib
and then mount that as/lib
in the host file system.wasi.py
has to mess around with settingPYTHONPATH
becauseprefix
is set to a path from the build machine. It would simplify this if we distinguish between:prefix
-- the path in the build file system where we want to install the fileshost_prefix
-- the path in the host file system where getpath.c will look for the filesAnd similarly for
exec_prefix
andhost_exec_prefix
.