[mono-runtimes] Rebuild mono when mono changes. #36
Conversation
This file contains hidden or 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
jonpryor
force-pushed
the
jonp-mono-rebuild
branch
from
e213864 to
2b44d4d
Compare
|
hold off on merging; it's not working quite right. |
The `mono-runtimes` project isn't resilient to mono changes, in large part because of the `_Autogen` target: `_Autogen` only executes if `$(_MonoPath)\autogen.sh` is newer than `$(_MonoPath)\configure`, and if the `_Autogen` target *doesn't* run, *no other targets* are re-executed either. Meaning if mono is bumped, e.g. as in commit cebaba2, the "newly updated" mono isn't necessarily rebuilt, because as far as the `_Autogen` target is concerned, nothing has changed (unless there is a commit which just happened to touch `autogen.sh`...which is a fairly infrequent occurrence). Add a new `_SetAutogenShTimeToLastCommitTimestamp` target which *always* touch(1)es `autogen.sh` to contain the timestamp of the most recent commit. That way, if (when) mono is updated, the timestamp of `autogen.sh` will be updated to match, allowing mono to be properly rebuilt. If mono *isn't* updated, the timestamp will be set to what it previously was, and no rebuild will occur. Note: `git log --date=format-local:...` must be used so that the resulting timestamp is in the *local* timezone. Otherwise, it's possible that if the current commit was done "in the future" relative to the current local timezone, `autogen.sh` will *always* have a more recent timestamp...until "tomorrow", anyway, and nobody wants to wait for "tomorrow".
jonpryor
force-pushed
the
jonp-mono-rebuild
branch
from
2b44d4d to
7a6d564
Compare
|
It wasn't working because of timezones. (Can you believe it?! Timezones) Specifically, commit cebaba2 bumped mono to a commit from Wed May 11 14:11:28 2016 +0200. As of the time of this writing, that was 10 hours ago. However, in my local timezone (USA EDT, UTC-4, "Wed May 11 17:49:42 EDT 2016"), that commit is 17 minutes in the future: So even though the commit was made 10+ hours ago, as far as the initial timestamp computation logic was concerned, it was ~17 minutes from now, so the Fun! |
radical
pushed a commit
that referenced
this pull request
May 8, 2018
[generator] Upgrade generator from monodroid/a438c473
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The
mono-runtimesproject isn't resilient to mono changes, in largepart because of the
_Autogentask: it only executes ifautogen.shis newer than
configure, and if it doesn't run, nothing elseis re-executed either.
Meaning if mono is bumped, e.g. in commit cebaba2, the "newly
updated" mono isn't necessarily rebuilt, because as far as the
_Autogentarget is concerned, nothing has changed (unless there is acommit which just happened to touch
autogen.sh...which is a fairlyinfrequent occurrence).
Add a new
_GetMonoTimestamptarget which always touch(1)esautogen.shto contain the timestamp of the most recent commit.THat way, if (when) mono is updated, the timestamp of
autogen.shwill be updated to match, allowing mono to be properly rebuilt.
If mono isn't updated, the timestamp will be set to what it
previously was, and no rebuild will occur.