[build] Fix the Linux build - #394
Merged
Merged
Conversation
As feared, commit 743529c's removal of `$(TargetFrameworkRootPath)` [broke the Linux build][0]: Gui/Activities/TestSuiteActivity.cs(25,35): error CS0012: The type `System.IDisposable' is defined in an assembly that is not referenced. Consider adding a reference to assembly `System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' macOS is unaffected as [it's unfortunately using System files][1]: Found framework definition list '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/RedistList/FrameworkList.xml' for framework 'MonoAndroid,Version=v1.0' (Heavy sigh.) Thus, our scenario: `msbuild` doesn't like setting `$(TargetFrameworkRootPath)`, yet `$(TargetFrameworkRootPath)` needs to be set for Linux to build, because Linux doesn't have a system-wide Xamarin.Android install. (Not that we want to require a Xamarin.Android install! But that's just why macOS is building...) The fix? Split the difference, somewhat. We can't set `$(TargetFrameworkRootPath)` for *everything*, but we *can* override it for *specific projects*. Update `Mono.Data.Sqlite.csproj`, `Mono.Posix.csproj`, `OpenTK.csproj`, `System.Drawing.Primitives.csproj`, and `Xamarin.Android.NUnitLite.csproj` to override `$(TargetFrameworkRootPath)` appropriately, so that they resolve the `MonoAndroid` framework assemblies from the internal build tree. What's left is `Mono.Android.csproj` and `Mono.Android.Export.csproj`, which don't `<Import/>` `Xamarin.Android.CSharp.targets`. These are the projects that needed to "hack in" a `@(Reference)` to `System.Runtime` in 7343965, which was removed in 743529c. The fix is more voodoo in each of them: * Set `$(ImplicitlyExpandDesignTimeFacades)`=True, so `System.Runtime` can be found * Set `$(TargetFrameworkIdentifier)`=MonoAndroid, so we're looking for the correct framework * Set `$(TargetFrameworkRootPath)` so that the MonoAndroid framework can be found in the local build tree. * Set `$(TargetFrameworkVersion)` to a valid MonoAndroid framework version number. This allows `Mono.Android.Export.csproj`. `Mono.Android.csproj` needs one more fix: in order for frameworks to be resolved from a "clean" state, `RedistList\FrameworkList.xml` must exist before attempting to resolve assemblies. Fix the `_GenerateFrameworkList` target so that `FrameworkList.xml` is created *before* the `ResolveReferences` target, thus allowing the `MonoAndroid,v7.1` framework to be found. [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-linux/173/ [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/207/consoleText
Contributor
|
changes look ok. If someone can confirm it works on line then I'll merge. @atsushieno @grendello ? |
jonpryor
added a commit
that referenced
this pull request
Jan 25, 2017
Reverts #394 (commit 61b21bc). [It broke the build][b209]: Java.Lang/Object.cs(15,5): error CS0012: The type `System.IDisposable' is defined in an assembly that is not referenced. Consider adding a reference to assembly `System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' Doubly odd, I *thought* that this had successfully gone through the PR builder, but I can't find an actual PR build for this PR! Revert the attempted Linux build fix. We want things building, which will allow me time to investigate a better Linux fix. [b209]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/209/
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jan 25, 2017
As feared, commit 743529c's removal of `$(TargetFrameworkRootPath)` [broke the Linux build][0]: Gui/Activities/TestSuiteActivity.cs(25,35): error CS0012: The type `System.IDisposable' is defined in an assembly that is not referenced. Consider adding a reference to assembly `System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' macOS is unaffected as [it's unfortunately using System files][1]: Found framework definition list '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/RedistList/FrameworkList.xml' for framework 'MonoAndroid,Version=v1.0' (Heavy sigh.) Thus, our scenario: `msbuild` doesn't like setting `$(TargetFrameworkRootPath)`, yet `$(TargetFrameworkRootPath)` needs to be set for Linux to build, because Linux doesn't have a system-wide Xamarin.Android install. (Not that we want to require a Xamarin.Android install! But that's just why macOS is building...) The fix? Split the difference, somewhat. We can't set `$(TargetFrameworkRootPath)` for *everything*, but we *can* override it for *specific projects*. Update `Mono.Data.Sqlite.csproj`, `Mono.Posix.csproj`, `OpenTK.csproj`, `System.Drawing.Primitives.csproj`, and `Xamarin.Android.NUnitLite.csproj` to override `$(TargetFrameworkRootPath)` appropriately, so that they resolve the `MonoAndroid` framework assemblies from the internal build tree. What's left is `Mono.Android.csproj` and `Mono.Android.Export.csproj`, which don't `<Import/>` `Xamarin.Android.CSharp.targets`. These are the projects that needed to "hack in" a `@(Reference)` to `System.Runtime` in 7343965, which was removed in 743529c. The fix is more voodoo in each of them: * Set `$(ImplicitlyExpandDesignTimeFacades)`=True, so `System.Runtime` can be found * Set `$(TargetFrameworkIdentifier)`=MonoAndroid, so we're looking for the correct framework * Set `$(TargetFrameworkRootPath)` so that the MonoAndroid framework can be found in the local build tree. * Set `$(TargetFrameworkVersion)` to a valid MonoAndroid framework version number. This allows `Mono.Android.Export.csproj`. `Mono.Android.csproj` needs one more fix: in order for frameworks to be resolved from a "clean" state, `RedistList\FrameworkList.xml` must exist before attempting to resolve assemblies. Fix the `_GenerateFrameworkList` target so that `FrameworkList.xml` is created *before* the `ResolveReferences` target, thus allowing the `MonoAndroid,v7.1` framework to be found. [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-linux/173/ [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/207/consoleText
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 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.
As feared, commit 743529c's removal of
$(TargetFrameworkRootPath)broke the Linux build:
macOS is unaffected as it's unfortunately using System files:
(Heavy sigh.)
Thus, our scenario:
msbuilddoesn't like setting$(TargetFrameworkRootPath), yet$(TargetFrameworkRootPath)needsto be set for Linux to build, because Linux doesn't have a system-wide
Xamarin.Android install. (Not that we want to require a
Xamarin.Android install! But that's just why macOS is building...)
The fix? Split the difference, somewhat. We can't set
$(TargetFrameworkRootPath)for everything, but we can overrideit for specific projects. Update
Mono.Data.Sqlite.csproj,Mono.Posix.csproj,OpenTK.csproj,System.Drawing.Primitives.csproj, andXamarin.Android.NUnitLite.csprojto override$(TargetFrameworkRootPath)appropriately, so that they resolve theMonoAndroidframework assemblies from the internal build tree.What's left is
Mono.Android.csprojandMono.Android.Export.csproj,which don't
<Import/>Xamarin.Android.CSharp.targets. These arethe projects that needed to "hack in" a
@(Reference)toSystem.Runtimein 7343965, which was removed in 743529c. The fix ismore voodoo in each of them:
$(ImplicitlyExpandDesignTimeFacades)=True, soSystem.Runtimecan be found
$(TargetFrameworkIdentifier)=MonoAndroid, so we're looking forthe correct framework
$(TargetFrameworkRootPath)so that the MonoAndroid frameworkcan be found in the local build tree.
$(TargetFrameworkVersion)to a valid MonoAndroid frameworkversion number.
This allows
Mono.Android.Export.csproj.Mono.Android.csprojneedsone more fix: in order for frameworks to be resolved from a "clean"
state,
RedistList\FrameworkList.xmlmust exist before attempting toresolve assemblies. Fix the
_GenerateFrameworkListtarget so thatFrameworkList.xmlis created before theResolveReferencestarget, thus allowing the
MonoAndroid,v7.1framework to be found.