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.

Sign up for GitHub

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

Jump to bottom

How to tell what version of the WASI-SDK is installed? #372

Closed

brettcannon opened this issue Jan 8, 2024 · 2 comments · Fixed by #392

Contributor

brettcannon commented Jan 8, 2024

E.g., is there a text file somewhere I can have users look at to tell me what they tried using? (Context: python/cpython#113516).

brettcannon mentioned this issue

Build fails with WASI SDK 21 python/cpython#113516

Closed

Collaborator

abrown commented Jan 8, 2024

Reading through the issue, I see what you mean. Usually it's apparent if the user shows the full path to Clang, e.g., /opt/wasi-sdk-20.0/bin/clang. But it seems reasonable to add a version file somewhere for this kind of situation.

Member

sbc100 commented Jan 8, 2024

Some kind of version.h header might be good idea

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Replace multiple version scripts with a Python script

436edaa

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.

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Dump a VERSION file in the build directory

67cf9b2

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.

abrown mentioned this issue

Replace the version scripts #392

Merged

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Replace multiple version scripts with a Python script

f23bb78

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.

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Dump a VERSION file in the build directory

ac4e279

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.

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Replace multiple version scripts with a Python script

950a092

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.

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Dump a VERSION file in the build directory

cb064fa

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.

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Replace multiple version scripts with a Python script

9e255c8

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.

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Dump a VERSION file in the build directory

9e72a4c

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.

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Replace multiple version scripts with a Python script

d0cafb9

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.

abrown added a commit to abrown/wasi-sdk that referenced this issue


          Dump a VERSION file in the build directory

5a17d2a

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.

abrown added a commit that referenced this issue


          Replace multiple version scripts with a Python script

2436b99

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.

abrown closed this as completed in #392

abrown added a commit that referenced this issue


          Dump a VERSION file in the build directory

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 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 #372.

PiCoPress pushed a commit to PiCoPress/wasi-sdk that referenced this issue


          Replace multiple version scripts with a Python script

c30909d

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.

PiCoPress pushed a commit to PiCoPress/wasi-sdk that referenced this issue


          Dump a VERSION file in the build directory

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment