Skip to content
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

Add version.h defining WASI_LIBC_VERSION #534

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

abrown
Copy link
Collaborator

@abrown abrown commented Sep 12, 2024

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:

// 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?>.

@abrown
Copy link
Collaborator Author

abrown commented Sep 12, 2024

CI error should be fixed in #535.

@yamt
Copy link
Contributor

yamt commented Sep 12, 2024

i wonder if the git requirement can make some people unhappy.
ie. you can't build from release tarballs like https://github.com/WebAssembly/wasi-libc/archive/refs/tags/wasi-sdk-22.tar.gz anymore.
i don't have a nice solution though.

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
@sbc100
Copy link
Member

sbc100 commented Sep 18, 2024

Won't this means that the version reported in the wasi-libc that is embedded in wasi-sdk is always at least one version behind because the building happens before the tagging? Or do we tag and then build (which also would seem odd)?

@sbc100
Copy link
Member

sbc100 commented Sep 18, 2024

i wonder if the git requirement can make some people unhappy. ie. you can't build from release tarballs like https://github.com/WebAssembly/wasi-libc/archive/refs/tags/wasi-sdk-22.tar.gz anymore. i don't have a nice solution though.

Normally with this kind of thing the release source archive would have version.h, and the git repository would have version.h.in. So only git developers would be regenerating version.h and there would be make dist process to go from a git checkout to a source archive.

Sadly in the age of github the automatic source snapshot is often used instead of the output of make dist so there is not (by default) as way to run this.

We could switch to a make dist approach instead of relying on github to automatically create snapshots of the git contents?

@abrown
Copy link
Collaborator Author

abrown commented Sep 18, 2024

Won't this means that the version reported in the wasi-libc that is embedded in wasi-sdk is always at least one version behind because the building happens before the tagging? Or do we tag and then build (which also would seem odd)?

Yeah, that's a good point. I'm just exploring what might work with these PRs. Seems like we probably should do the replacement over in WebAssembly/wasi-sdk#487 but maybe wasi-libc could just contain a token value like #define WASI_LIBC_VERSION "dev".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants