Itiviti / gradle-msbuild-plugin

Gradle plugin for msbuild execution, supports C# project files for now
Apache License 2.0
101 stars 57 forks source link

Solution file parsing removed for empty projectName #33

Closed tekuser closed 9 years ago

tekuser commented 9 years ago

In issue https://github.com/Ullink/gradle-msbuild-plugin/issues/31 : Warning message: Project XXX found in solution, disabling input/output optimizations

I have a committed a fix to avoid the warning message when the projectName is null, i.e. when we want to build the whole solution.

In the fix, we still continue to parse the solution file even if the projectName is null. I have corrected it in the current pull request. Now, if the projectName is null, we don't parse the solution file and there is no input/output optimization.

gluck commented 9 years ago

Hi

what's the motivation to remove the solution parsing ? it gives the end-user access to all project properties, evaluated, hence it's usually very useful in the build chain (e.g. get project binaries, output folder, source files, SDK versions of whatever).

Thx

tekuser commented 9 years ago

Hi, We have a very big C++ solution file (with a lot of projects). It was quite badly designed: so it will take time to split it into small libraries.

So the solution file parsing by the plugin takes some time. It is ok when we want to launch a build as the compilation time is largely bigger than the parsing time. But, when we want to launch small gradle tasks, such as "gradle tasks" or our dependency resolver, the parsing time takes too much time up to 1min (on a laptop with i5 4Gb, 5400rpm HD). The gradle build will be used for CI and for dependency downloading and install. The dev should be able to fully compile with Visual Studio and Gradle.

For us, only the input and output files are relevant to use the gradle up-to-date process ; we can also rely on the msbuild incremental build.

Moreover, we can also have multiple solution files according to the version of Visual Studio.

If my modification is irrelevant as it seems to be in the case one wants to use the information contained in the solution/project files. I can solve my issue by using something like that:

task buildSolution1 <<{ msbuild{...}.execute() }

instead of: task buildSolution1(type: Msbuild) {...}

So maybe we should reject my pull request as it is for a special use case.

gluck commented 9 years ago

How about parsing the project only is something tries to access the project properties ? (if project name is null, we could remove the calls)

gluck commented 9 years ago

(wondering why the parsing takes that long though, as it shouldn't execute anything, neither read any source file content, simply parse *proj files, and read some registry keys, write some JSON)

Any (even vague) clue about that ? probably can't do a thing if that's MS.Build related, but it could be the json mapping/writing ?

tekuser commented 9 years ago

Well, I don't have any idea why it takes so much time. I didn't investigate because I thought it was due to our laptops. And I am pretty sure it is due to that and we have a lot cpp and h files. Even unzipping with gradle is quite slow. Our use case is also a special use case.

When I proposed to by-pass the project parsing, I didn't thought about accessing the project properties. So I think it is better to keep the code as it is and I will do something like that msbuild{...}.execute().