[Xamarin.Android.Build.Tasks] Fix incremental rebuilds (Take 2!) #24
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
Rebuilding the Xamarin.Android.Build.Tasks project would fail: $ xbuild # works # "change a file $ touch Tasks/Aapt.cs # Rebuild; should work, right? $ xbuild Tasks/LinkAssemblies.cs(103,32): error CS0117: `Xamarin.Android.Tasks.Profile' does not contain a definition for `SharedRuntimeAssemblies' Utilities/MonoAndroidHelper.cs(230,16): error CS0117: `Xamarin.Android.Tasks.Profile' does not contain a definition for `SharedRuntimeAssemblies' # wat? The problem was due to a3dfd4c *and* 59ec488: 1. In 59ec488, `Xamarin.Android.Build.Tasks.targets` was included *before* including `$(MSBuildToolsPath)\Microsoft.CSharp.targets`. This meant that `$(IntermediateOutputPath)` wasn't set when `Xamarin.Android.Build.Tasks.targets` was imported, and thus `$(_GeneratedProfileClass)` contained no directory name. 2. In a3dfd4c, the `@(Compile)` item group was only updated when the `_GenerateProfileClass` target was executed, which only happened when `$(_GeneratedProfileClass)` didn't exist. This is why it works on the initial build but not subsequent builds. Things worked prior to a3dfd4c because the `_Foo` target *always* executed, and thus `@(Compile)` always contained the generated Profile.g.cs file. Fix the `<Import/>` ordering issue (1), and instead of updating `@(Compile)` when the target executes, just add the generated file to `@(Compile)` within Xamarin.Android.Build.Tasks.csproj (2).
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Dec 14, 2020
Changes: mono/opentk@197827f...933939d * mono/opentk@933939da: Link Code of Conduct (dotnet#24)
jonpryor
added a commit
that referenced
this pull request
Dec 15, 2020
Changes: mono/opentk@197827f...933939d * mono/opentk@933939da: Link Code of Conduct (#24)
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.
Rebuilding the Xamarin.Android.Build.Tasks project would fail:
The problem was due to a3dfd4c and 59ec488:
Xamarin.Android.Build.Tasks.targetswas includedbefore including
$(MSBuildToolsPath)\Microsoft.CSharp.targets.This meant that
$(IntermediateOutputPath)wasn't set whenXamarin.Android.Build.Tasks.targetswas imported, and thus$(_GeneratedProfileClass)contained no directory name.@(Compile)item group was only updated when the_GenerateProfileClasstarget was executed, which only happenedwhen
$(_GeneratedProfileClass)didn't exist. This is why itworks on the initial build but not subsequent builds.
Things worked prior to a3dfd4c because the
_Footarget alwaysexecuted, and thus
@(Compile)always contained the generatedProfile.g.cs file.
Fix the
<Import/>ordering issue (1), and instead of updating@(Compile)when the target executes, just add the generated file to@(Compile)within Xamarin.Android.Build.Tasks.csproj (2).