Bug 4642 - Sometimes things are rebuilt that aren't out of date
Summary: Sometimes things are rebuilt that aren't out of date
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.1.x
Hardware: PC Windows
: --- critical
Target Milestone: ---
Assignee: dean.ellis
Depends on:
Reported: 2012-04-25 10:53 UTC by Jonathan Pobst
Modified: 2013-01-23 23:17 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jonathan Pobst 2012-04-25 10:53:01 UTC
MSBuild can get into a state where it always re-runs aapt (which is costly) because the .csproj is newer than the resources.
Comment 3 Atsushi Eno 2012-09-18 03:46:03 UTC
This is not likely to happen with the latest monodroid (internal master), I tried with xbuild.
Comment 4 Atsushi Eno 2012-10-18 13:00:56 UTC
Well, this actually happened when I explicitly touched *.csproj file so that it becomes newer than any resources.
Comment 6 Jonathan Pryor 2013-01-23 18:20:43 UTC
Migrating this to a "WTF is wrong with our build system" task...

Related issue: timestamps! There is a project that was taking > 3m to rebuild with no changes, i.e.

    $ xbuild /t:Install /v:diag > install-1.txt
    $ xbuild /t:Install /v:diag > install-2.txt

No changes, yet install-2.txt took > 3m to execute.

Many of the messages were:

> Target _GenerateAndroidResourceDir needs to be built as input file 'Resources/layout/layout.axml' is newer than output file '.../obj/Debug/res/layout/whatever.xml'

Which was correct:

> -rw-r--r--  1 boo  staff  1598 Jan 22 14:53 Resources/layout/layout.axml
> -rwxr-xr-x  1 boo  staff  11749 Oct  9 11:03 .../obj/Debug/res/layout/whatever.xml

Updating the timestamps of the files and rebuilding:

    $ find .../obj/Debug/res -type f -exec touch {} \;
    $ xbuild /t:Install /v:diag > install-2.txt

took > 1m off the build time. Resulting time was still nearly 2m, but that's better than 3m.
Comment 7 Jonathan Pryor 2013-01-23 18:56:52 UTC
The _CreateBaseApk target creates $(IntermediateOutputPath)android\bin\packaged_resources, which may not be updated or touched. The result is that  _CreateBaseApk may be re-executed when it isn't necessary; touching packaged_resources removes it.

Touching obj/Debug/android/bin/packaged_resources allows the _CreateBaseApk target to be skipped.
Comment 8 Jonathan Pryor 2013-01-23 19:17:34 UTC
The general summary of most of these is that we need to be more rigorous about updating timestamps. When:

1. Create a "new" file.
2. Compare "new" file contents to "old" file contents
3. File contents are the same

We currently "ignore" the new file, and leave the "old" file unchanged.


By leaving the "old" file unchanged, MSBuild (using timestamps) thinks that the file hasn't been updated, so the next time MSBuild executes, it will re-execute the task to create the file.

Over. And over. And over.

What we should instead do is when the file contents are the same, we should touch the old file so that the timestamp is updated. MSBuild can then treat the file as up-to-date, and won't re-execute the target next time.
Comment 9 Stephen Shaw 2013-01-23 19:22:31 UTC
And over.
Comment 10 Jonathan Pryor 2013-01-23 23:17:17 UTC
(Hopefully?) fixed in monodroid/4b41c673.