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

[ci] Build without -m:1. #941

Merged
merged 1 commit into from
Jan 24, 2022
Merged

[ci] Build without -m:1. #941

merged 1 commit into from
Jan 24, 2022

Conversation

jpobst
Copy link
Contributor

@jpobst jpobst commented Jan 18, 2022

Fix parallel build issues to allow us to build Java.Interop.sln without needing -m:1 on dotnet build.

Changes:

  • Remove Java.Interop.BootstrapTasks.csproj from Java.Interop.sln and create a Java.Interop.BootstrapTasks.sln for -t:Prepare to run. This mirrors what XA does and keeps it from being rebuilt during the main run (at the same time other projects are trying to use Java.Interop.BootstrapTasks.dll).
  • We need to add a Restore for Java.Interop.BootstrapTasks.csproj because it's no longer in Java.Interop.sln, but it has to be a separate invocation from the Build.
  • Don't call GenerateVersionInfo target for Java.Interop.BootstrapTasks because it requires itself to already be built to run. It doesn't make much sense to version this assembly anyways since we do not ship it.
  • Ordering our custom targets with BeforeTargets="BeforeBuild" is problematic, because it runs before referenced projects are built. Switch to Build or BeforeCompile as needed.

Tested in XA with: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5651052&view=results.

@jpobst jpobst force-pushed the parallel-build branch 4 times, most recently from 29c6f84 to 5889d4a Compare January 20, 2022 20:54
@jpobst jpobst marked this pull request as ready for review January 24, 2022 16:49
Copy link
Member

@jonathanpeppers jonathanpeppers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What you have here works -- and seems like the same approach we have in xamarin-android.

I also heard about this repo:

https://github.com/rainersigwald/build-task-in-solution-demo

Anywhere we are using "bootstrap" MSBuild tasks, we could potentially do:

https://github.com/rainersigwald/build-task-in-solution-demo/blob/17508937bb9edb0b817820146f85adf0da331515/Task/DemoFunctionality.targets#L4-L10

TaskFactory="TaskHostFactory" supposedly closes down the task after each call, and prevents file locking. Is it worth trying this out, and we could keep one .sln file?

@jpobst
Copy link
Contributor Author

jpobst commented Jan 24, 2022

Oh, interesting. Maybe in the future I can use that to eliminate the "Prepare" step like I want to...

For now, since we have to have the Prepare step for other reasons I guess we can stick with this mechanism.

It sounds like the alternative would be a bit slower:

force MSBuild to load a new copy of the assembly in a new process for every execution of the task

@jonpryor jonpryor merged commit 88d6093 into main Jan 24, 2022
@jonpryor jonpryor deleted the parallel-build branch January 24, 2022 20:40
@github-actions github-actions bot locked and limited conversation to collaborators Apr 13, 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.

3 participants