Daniel Lacasse

Thanks @adammurdoch for the word of wisdom of splitting the change into measurable units. I did just that and I created PR https://github.com/gradle/gradle/pull/4616 containing the most impactful change.

PR https://github.com/gradle/gradle/pull/4617 is based on the previous PR and shows the additional changes that allow Gradle to come within ~500ms of the Gradle 4.2.1 performance.

I closed the unmerged PR as my experimentation so far have only produced incorrect result or a regression.

Instead of looking at caching more result, I decided to look at the root cause of why some headers are flagged with `HasMacroInclude`. Disclaimer, improving these following scenario may have...

The performance for 4.2.1 with the updated code on https://github.com/lacasseio/boost-asio is

@ThadHouse Is what you are seeing Gradle snapshotting all the header files and an info log saying it's reverting to taking all the headers into account?

It was noted this use case is common among software model users and block users from moving to the new C++ plugins.

GCC's gcov and then lcov to render an HTML report for the coverage is one of the use case.

Sure thing @eriwen. Thanks for the issue @zosrothko. My biggest concern regarding the [proposed fix](https://github.com/Kampbell/gradle/commit/84265cee8ffecf7c32c2f7df418ffbb54f087ff7) is how specific to Windows development it is. The same goes with the resource compiler....

Thanks for the extended user case. The generic solution for all those compilers would be to use the generated source set. Unfortunately, we don't get to easily configure the compiler...