-
Notifications
You must be signed in to change notification settings - Fork 191
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
Replace the version scripts #392
Conversation
For reference,
|
51aa8ac
to
d4f5bbf
Compare
Looks like the Docker issue, when replicated locally, is due to the |
I came across this in WebAssembly#392, where it became clear that Ubuntu's 18.04 release (now several years old) was using quite ancient versions of certain tools.
In the past, I've had trouble keeping the current set of version scripts to correctly output the version, especially in light of how we append Git suffixes for a non-tagged commit and dirty state. This change replaces those scripts with a single Python one which, though much more wordy than the previous one, may be easier for contributors to read and modify. The original scripts relied on Perl; this one relies on Python, which seems like a fair exchange. Having a single script also makes it easier to solve WebAssembly#372.
As noted in WebAssembly#372, some users may need to identify which version of wasi-sdk they are using after it has been downloaded. There are many ways to solve this, but the one I chose here is to dump the wasi-sdk version into a `VERSION` file and follow that up with several dependency versions that may be helpful to note when troubleshooting. Ideally someone could paste the contents of that file when filing a bug. If we adopt this approach, this fixes WebAssembly#372.
When running Git commands inside this Docker container (i.e., commands that the `version.py` script needs for determining version information), the Docker build would run into issues like: ``` fatal: detected dubious ownership in repository at '/workspace' To add an exception for this directory, call: git config --global --add safe.directory /workspace ``` This is due to an extra Git check that detects that the Docker user is not the same one who owns the `.git` directory of this project. After looking into this, the best solution the internet has to offer is to thread the current user's UID and GID through the Docker image (i.e., the new `builder` user) and then `docker run --user ...`. This both avoids the Git check but also seems to be considered a best practice in some circles (?).
In WebAssembly#399, @glandium points out that newer versions of LLVM will place their version information at a different path. This change adapts WebAssembly#399 to the new Python version script.
@sbc100, @sunfishcode: I rebased this change and re-split the commits as atomic changes on top of |
This commit fixes a minor mistake from WebAssembly#392 where the previous perl script had a special case that if the "minor" version was zero then the git hash information wouldn't be printed.
This commit fixes a minor mistake from #392 where the previous perl script had a special case that if the "minor" version was zero then the git hash information wouldn't be printed.
In the past, I've had trouble keeping the current set of version scripts
to correctly output the version, especially in light of how we append
Git suffixes for a non-tagged commit and dirty state. This change
replaces those scripts with a single Python one which, though much more
wordy than the previous one, may be easier for contributors to read and
modify. The original scripts relied on Perl; this one relies on Python,
which seems like a fair exchange. Having a single script also makes it
easier to solve #372.
As noted in #372, some users may need to identify which version of
wasi-sdk they are using after it has been downloaded. There are many
ways to solve this, but the one I chose here is to dump the wasi-sdk
version into a
VERSION
file and follow that up with several dependencyversions that may be helpful to note when troubleshooting. Ideally
someone could paste the contents of that file when filing a bug. If we
adopt this approach, this fixes #372.