Inject a source identifer into moc
#1631
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I have been preaching this for so long to other teams, I really better
clean up my own backyard: Make sure that you can run
moc --version
and get a somewhat useful indication what version that is. This is
important for when random people use `moc` from random versions of SDK
or – later – build it themselves and then provide bug reports.
When building locally, with `.git` around, this now injects the git
revision:
$ ./moc --version
Motoko compiler (revision 9abae15e-dirty)
(the `-dirty` indicates that my work-tee is not clean).
When `.git` is _not_ available, as typially (and rightfully) when
building with nix, it looks if Nix’s `$out` variable is set, and
includes that:
~/dfinity/motoko $ $(nix-build -A moc)/bin/moc --version
Motoko compiler (revision xx6fmamdh5bjph9law6x02d7f4hw8f84-moc-bin)
This is less useful for end-users, but it still allows us to (hopefully)
identify the version, in the worst case by running this command on all
revisions to find the right one:
$ nix-store --query --outputs $(nix-instantiate -A moc-bin)
/nix/store/xx6fmamdh5bjph9law6x02d7f4hw8f84-moc-bin
Or by querying hydra (as @basvandijk suggests in
dfinity/sdk#383 (comment))
Once we do versioned releases, we can of course extend this to inject
the version number there, and use `git describe --tag` to have
`v1.0-200-9abae15e` like derscriptions.
I _hope_ this will not cause extra recompilations with `dune`, and will
work out-of-the box for everyone, but we’ll see.
|
This PR does not affect the produced WebAssembly code. |
so that it will hopefully not be picked up as a “dependency”
so that it does not get picked up by `common.lib.standaloneRust`
ggreif
approved these changes
Jun 21, 2020
There was a problem hiding this comment.
I appreciate this heroic move! Looks good to me, but since version-injection schemes are highly fragile, only time will tell. Hopefully @basvandijk can chime in for the nix parts.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have been preaching this for so long to other teams, I really better
clean up my own backyard: Make sure that you can run
and get a somewhat useful indication what version that is. This is
important for when random people use
mocfrom random versions of SDKor – later – build it themselves and then provide bug reports.
When building locally, with
.gitaround, this now injects the gitrevision:
(the
-dirtyindicates that my work-tree is not clean).When
.gitis not available, as typically (and rightfully) whenbuilding with nix, it looks if Nix’s
$outvariable is set, andincludes that:
This is less useful for end-users, but it still allows us to (hopefully)
identify the version, in the worst case by running this command on all
revisions to find the right one:
Note that I injected dashes into the id so that it does not trip up
common.lib.standaloneRustwhich otherwise would take it for anunwanted dependency.
@basvandijk suggests in
dfinity/sdk#383 (comment) that one
may query Hydra’s database to map from id to revision.
Once we do versioned releases, we can of course extend this to inject
the version number there, and use
git describe --tagto havev1.0-200-9abae15elike descriptions.I hope this will not cause extra recompilations with
dune, and willwork out-of-the box for everyone, but we’ll see.