Publish header with toolchain versions #487
Conversation
This change is an attempt to resolve [wasi-libc#490] but at the wasi-sdk level. It adds a `version.h` header file to `share/wasi-sysroot/include/<target>/wasi` so that users have programmatic access to some extra information to output better error messages, e.g. This `version.h` looks something like: ```c // Generated by wasi-sdk's `version.py` script. #ifndef VERSION_H #define VERSION_H #define WASI_SDK_VERSION "24.6g754aec3d6f58+m" #define WASI_LIBC_VERSION "b9ef79d7dbd4" #endif ``` It _is_ a bit strange that we're adding to wasi-libc's include files from wasi-sdk (it would be cleaner if it happened in wasi-libc directly) but wasi-sdk actually has the information available. [wasi-libc#490]: WebAssembly/wasi-libc#490
abrown
force-pushed
the
version-header
branch
from
92c5bce
to
aa33732
Compare
| file(GENERATE OUTPUT ${version_header_path} CONTENT ${version_header}) | ||
| add_custom_target(version-header-${target} DEPENDS ${version_header_path}) | ||
| add_dependencies(build version-header-${target}) | ||
| endforeach() |
There was a problem hiding this comment.
A more traditional cmake way of doing this would be to create a template file called version.h that looks like this:
#ifndef VERSION_H
#define WASI_SDK_VERSION @WASI_SDK_VERSION@
#define WASI_LIBC_VERSION @WASI_LIBC_VERSION@
#endif
And then use configure_file : https://cmake.org/cmake/help/latest/command/configure_file.html
Then you would just need to set WASI_LIBC_VERSION and WASI_SDK_VERSION as cmake variables (presumably still by running version.py.. but without needing to add anything new to version.py I would hope).
There was a problem hiding this comment.
I like that better for the most part but I was worried about having a non-functional file cause problems. That approach means that we would add a non-functional version.h file to wasi-libc that kind of hangs around un-configured until it is seen by wasi-sdk. For those users who interact with wasi-libc directly (not through wasi-sdk), wouldn't they see an error if they included that un-configured version.h?
There was a problem hiding this comment.
Oh, sorry, the non-functional file is called version.h.in.. which is used to create the functional version.h, so they won't be confused.
|
Thanks very much for looking into this! This would solve our problem very neatly! To be clear, would I want to include |
I think you would include |
@grynspan, I think it would be |
yes. |
This change re-imagines [wasi-sdk#487] entirely in `wasi-libc`. Instead of generating a `version.h` header late--in `wasi-sdk`--it is generated immediately when `wasi-libc` is built. This has the disadvantage that we don't know what `wasi-sdk` this will be used in... but almost: when releasing `wasi-sdk`, we _should_ be tagging the `wasi-libc` repository. If we did that more faithfully ([docs]), this commit would generate: ```c // Generated by wasi-lib's `Makefile`. #ifndef VERSION_H #define VERSION_H #define WASI_LIBC_VERSION "wasi-sdk-24" #endif ``` Using the magic of `git-describe`, if someone is using `wasi-libc` directly, they may see a version like: `wasi-sdk-22-19-g5d3c5e9-dirty`. This should be read like: `<wasi-sdk tag>-<# commits since tag>-<current commit>-<is the repository dirty?>`. [wasi-sdk#487]: WebAssembly/wasi-sdk#487 [docs]: https://github.com/WebAssembly/wasi-sdk/blob/754aec3/RELEASING.md?plain=1#L22
|
If we did this exclusively in wasi-libc it could look like: WebAssembly/wasi-libc#534. |
|
Could the two be combined? Such that -libc provides its version and -sdk provides its version? |
This change re-imagines [wasi-sdk#487] entirely in `wasi-libc`. Instead of generating a `version.h` header late--in `wasi-sdk`--it is generated immediately when `wasi-libc` is built. This has the disadvantage that we don't know what `wasi-sdk` this will be used in... but almost: when releasing `wasi-sdk`, we _should_ be tagging the `wasi-libc` repository. If we did that more faithfully ([docs]), this commit would generate: ```c // Generated by wasi-lib's `Makefile`. #ifndef VERSION_H #define VERSION_H #define WASI_LIBC_VERSION "wasi-sdk-24" #endif ``` Using the magic of `git-describe`, if someone is using `wasi-libc` directly, they may see a version like: `wasi-sdk-22-19-g5d3c5e9-dirty`. This should be read like: `<wasi-sdk tag>-<# commits since tag>-<current commit>-<is the repository dirty?>`. [wasi-sdk#487]: WebAssembly/wasi-sdk#487 [docs]: https://github.com/WebAssembly/wasi-sdk/blob/754aec3/RELEASING.md?plain=1#L22
This change is an attempt to resolve wasi-libc#490 but at the wasi-sdk level. It adds a
version.hheader file toshare/wasi-sysroot/include/<target>/wasiso that users have programmatic access to some extra information to output better error messages, e.g. Thisversion.hlooks something like:It is a bit strange that we're adding to wasi-libc's include files from wasi-sdk (it would be cleaner if it happened in wasi-libc directly) but wasi-sdk actually has the information available.