[build] Bump mxe and add commit sha to AndroidMxeInstallPrefix #919
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
added
the
full-mono-integration-build
Contributor
|
build |
Contributor
|
The most recent commit does not appear to have improved matters: One gets the feeling that patch(1), somehow, has a bad library reference. Further confounding/confusing is why
Why isn't Something is very weird here. :-( |
This ensures that we can revert mxe to an earlier version. Background: The current "do we need to rebuild <dependency>" is mostly "forward-only". It works properly if you bump forward in time, but if you go _backwards_, it won't rebuild because it's timestamp based. For example: if we bump MXE, it'll rebuild the (cached!) MXE on the build server but if we find that MXE is broken and we need to revert... we can't because what we're reverting to is older than the bump! -- The new mxe now includes a few more "native" plugins in `plugins/native/<OS_SHORT_NAME>`. This caused issues on OSX where the `patch` that mxe built ran into a problem because it relied on newer APIs not available in older OSX. To fix this we just disable building the native plugins and rely on the system ones to be working. This is what mxe is doing on Travis: https://github.com/mxe/mxe/blob/16acc77a3d45425d5a7e11d8b2511fc5a28dd56f/.travis.yml#L6
akoeplinger
force-pushed
the
mxe-bump-and-cache-counter
branch
from
9b32dae to
8b83f7e
Compare
Member
Author
|
This should be good to go now. We removed building |
Redth
pushed a commit
to Redth/xamarin-android
that referenced
this pull request
Oct 30, 2017
Add commit SHA1 to `$(AndroidMxeInstallPrefix)`, so that we can revert mxe to an earlier version. Most of the current "do not rebuild DEPENDENCY" logic is "forward-only": it only works properly if you go *forward* in time, not backwards in time. For example, consider the `ForceBuild` target in `build-tools/mono-runtimes/mono-runtimes.targets`: if the HEAD commit within `external/mono` moves "backward" so that the resulting timestamp of `autogen.sh` is *older* than e.g. `bin\$(Configuration)\bcl-tests\bcl-tests.zip`, re-running the `ForceBuild` target won't do anything. `external/mono` and `mono-runtimes` are forward-only. Usually this is considered acceptable. If it's truly a problem, nuke the `bin` directory and rebuild. "Forward-only" behavior is *not* always acceptable. Case in point: `external/mxe`. Building MXE takes a significant amount of time -- roughly 10+ minutes -- so we *cache* the MXE toolchain into `$(AndroidMxeInstallPrefix)` -- which defaulted to `$HOME/android-toolchain/mxe` -- and only rebuild the cached MXE when `external/mxe` changes. All well and good...except when MXE *cannot* be built *at all*. Case in point: [MXE couldn't be built with Xcode 8.3][mxe1744]. We didn't notice this for a long period of time, because our Jenkins machines are fairly stable; they built and cached MXE under Xcode 8.1, and never had to rebuild MXE again. [mxe1744]: mxe/mxe#1744 The only reason we noticed is because some developers tried to build MXE on new machines, with newer Xcode versions, and MXE didn't build. This raises an interesting conundrum: for *cached* resources such as MXE, it is *extremely* important to be able to *revert* to a "known good" version. "Forward only" behavior is at odds with this; you *can't* revert to a "known good" version, because it may have been replaced! Bump to mxe/xamarin/a926b16d, as this version *can* be built under Xcode 9. (If we're lucky, it will *also* be able to build an updated commit of `external/libzip`…) Additionally, alter the semantics of `$(AndroidMxeInstallPrefix)` to *require* that it *ends with* the abbreviated commit hash of the `external/mxe` commit; in this commit, `$(AndroidMxeInstallPrefix)` is `$HOME/android-toolchain/mxe-a926b16d`. In particular, this allows us to *revert*: bumping `external/mxe` will build MXE into a new, *unique*, directory, which means that any previously built directory will not be modified. This in turn allows us to "revert" the patch to use the previous MXE, if necessary. The updated MXE now includes a few more "native" plugins in `plugins/native/$(OS_SHORT_NAME)`. This caused issues on macOS where the `patch` that MXE built ran into a problem because it relied on newer APIs not available in older versions of macOS. Fix this by disabling building the native plugins and instead rely on the system ones by overriding `$(OS_SHORT_NAME)`. [This mirrors what MXE is doing on Travis][travis]. [travis]: https://github.com/mxe/mxe/blob/16acc77a3d45425d5a7e11d8b2511fc5a28dd56f/.travis.yml#L6
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Nov 30, 2021
Fixes: dotnet/java-interop#815 Fixes: dotnet/java-interop#920 Changes: dotnet/java-interop@0293360...7f1a5ab * dotnet/java-interop@7f1a5ab1: [JavaTypeSystem] Enable resolving generic types on declaring types (dotnet#916) * dotnet/java-interop@8daa0263: [Xamarin.Android.Tools.Bytecode] Fix Nullability warnings (dotnet#922) * dotnet/java-interop@77c9c5fa: [class-parse] Import parameter names for unresolvable types (dotnet#921) * dotnet/java-interop@a8b444d5: [Java.Interop.Tools.JavaTypeSystem] ctors w/ generic type parameters (dotnet#919)
jonpryor
added a commit
that referenced
this pull request
Nov 30, 2021
Fixes: dotnet/java-interop#815 Fixes: dotnet/java-interop#920 Changes: dotnet/java-interop@0293360...7f1a5ab * dotnet/java-interop@7f1a5ab1: [JavaTypeSystem] Enable resolving generic types on declaring types (#916) * dotnet/java-interop@8daa0263: [Xamarin.Android.Tools.Bytecode] Fix Nullability warnings (#922) * dotnet/java-interop@77c9c5fa: [class-parse] Import parameter names for unresolvable types (#921) * dotnet/java-interop@a8b444d5: [Java.Interop.Tools.JavaTypeSystem] ctors w/ generic type parameters (#919)
jonathanpeppers
pushed a commit
that referenced
this pull request
Nov 30, 2021
Fixes: dotnet/java-interop#815 Fixes: dotnet/java-interop#920 Changes: dotnet/java-interop@0293360...7f1a5ab * dotnet/java-interop@7f1a5ab1: [JavaTypeSystem] Enable resolving generic types on declaring types (#916) * dotnet/java-interop@8daa0263: [Xamarin.Android.Tools.Bytecode] Fix Nullability warnings (#922) * dotnet/java-interop@77c9c5fa: [class-parse] Import parameter names for unresolvable types (#921) * dotnet/java-interop@a8b444d5: [Java.Interop.Tools.JavaTypeSystem] ctors w/ generic type parameters (#919)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
This ensures that we can revert mxe to an earlier version.
Background:
The current "do we need to rebuild " is mostly "forward-only". It works properly if you bump forward in time, but if you go backwards, it won't rebuild because it's timestamp based.
For example: if we bump MXE, it'll rebuild the (cached!) MXE on the build server but if we find that MXE is broken and we need to revert... we can't because what we're reverting to is older than the bump!