Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Xamarin.Android.Build.Tasks] fix _CompileJava running too often #2207

Merged
merged 1 commit into from
Sep 21, 2018

Conversation

jonathanpeppers
Copy link
Member

Context: #2088
Context: #2129
Context: #2199

In 4deec52, I fixed the #deletebinobj problem we discovered.

However...

I introduced a regression to incremental builds, I noticed that the
_CompileJava target is now running on a second build with no
changes. Third build? oddly it gets skipped...

It seems to be due to our use of flag files:

  1. _UpdateAndroidResgen updates R.cs.flag and uses the file as an
    output
  2. _GenerateJavaDesignerForComponent now uses R.cs.flag as an
    input
  3. _GenerateJavaStubs also updates the timestamp on R.cs.flag.
    This was added in 970da9e, as a workaround for our two instances
    of ConvertResourcesCases.
  4. _GenerateJavaDesignerForComponent will now run again on the next
    build.

Since 1886e6f eliminated the second call to ConvertResourcesCases,
we don't need to update R.cs.flag in no. 3 any longer.

Removing the call to <Touch /> R.cs.flag in _GenerateJavaStubs
fixed the issue, and I added some assertions in relevant tests to
check that the _CompileJava and _GenerateJavaDesignerForComponent
targets aren't running on incremental builds.

Context: dotnet#2088
Context: dotnet#2129
Context: dotnet#2199

In 4deec52, I fixed the #deletebinobj problem we discovered.

However...

I introduced a regression to incremental builds, I noticed that the
`_CompileJava` target is now running on a second build with no
changes. Third build? oddly it gets skipped...

It seems to be due to our use of flag files:
1. `_UpdateAndroidResgen` updates `R.cs.flag` and uses the file as an
   output
2. `_GenerateJavaDesignerForComponent` now uses `R.cs.flag` as an
   input
3. `_GenerateJavaStubs` *also* updates the timestamp on `R.cs.flag`.
   This was added in 970da9e, as a workaround for our two instances
   of `ConvertResourcesCases`.
4. `_GenerateJavaDesignerForComponent` will now run again on the next
   build.

Since 1886e6f eliminated the second call to `ConvertResourcesCases`,
we don't need to update `R.cs.flag` in no. 3 any longer.

Removing the call to `<Touch />` `R.cs.flag` in `_GenerateJavaStubs`
fixed the issue, and I added some assertions in relevant tests to
check that the `_CompileJava` and `_GenerateJavaDesignerForComponent`
targets aren't running on incremental builds.
@dellis1972
Copy link
Contributor

Mac Failure is un related. If the windows build passes I will merge this

@dellis1972 dellis1972 merged commit 647659e into dotnet:master Sep 21, 2018
@jonathanpeppers jonathanpeppers deleted the fix-compilejava branch September 21, 2018 14:04
@github-actions github-actions bot locked and limited conversation to collaborators Feb 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants