Skip to content

Conversation

@jonpryor
Copy link
Contributor

Context: 944f88a

Commit 944f88a enabled parallel builds by removing dotnet build -m:1
usage, which allows for faster incremental builds.

One of the problems encountered was around gradlew usage: gradlew
doesn't support multiple concurrent executions, and will block
waiting for other gradlew builds to complete, which can result in
timeouts and failed builds.

Commit 944f88a fixed this by "serializing" all projects which
involve gradlew:

  • r8.csproj is the "entrypoint"
  • r8.csproj references manifestmerger.csproj
  • manifestmerger.csproj references apksigner.csproj

This arrangement would cause dotnet build to sequentially build
r8.csproj, manifestmerger.csproj, and apksigner.csproj, ensuring
that only one gradlew command was run at a time.

Unfortunately, we overlooked
external/Java.Interop/tools/java-source-utils/java-source-utils.csproj.
Thus, we occasionally see the Windows build fail:

Timeout waiting to connect to the Gradle daemon.
…
…/java-source-utils.targets(10,5): error MSB3073: The command
  ""C:\a\_work\1\s\external\Java.Interop\build-tools\gradle\gradlew" …"
  exited with code 1.

Update apksigner.csproj to reference java-source-utils.csproj,
extending the "sequential order" of gradlew-using projects.
This should make the Windows build more reliable.

Additionally, move the <Target/>s out of apksigner.csproj and
into apksigner.targets. This is more consistent with other
projects, and reduces the likelihood of VSMac rewriting (and removing
the formatting of) apksigner.csproj.

Context: 944f88a

Commit 944f88a enabled parallel builds by removing `dotnet build -m:1`
usage, which allows for faster incremental builds.

One of the problems encountered was around `gradlew` usage: `gradlew`
doesn't support multiple concurrent executions, and will *block*
waiting for other `gradlew` builds to complete, which can result in
timeouts and failed builds.

Commit 944f88a fixed this by "serializing" all projects which
involve `gradlew`:

  * `r8.csproj` is the "entrypoint"
  * `r8.csproj` references `manifestmerger.csproj`
  * `manifestmerger.csproj` references `apksigner.csproj`

This arrangement would cause `dotnet build` to sequentially build
`r8.csproj`, `manifestmerger.csproj`, and `apksigner.csproj`, ensuring
that only one `gradlew` command was run at a time.

Unfortunately, we overlooked
`external/Java.Interop/tools/java-source-utils/java-source-utils.csproj`.
Thus, we occasionally see the Windows build fail:

	Timeout waiting to connect to the Gradle daemon.
	…
	…/java-source-utils.targets(10,5): error MSB3073: The command
	  ""C:\a\_work\1\s\external\Java.Interop\build-tools\gradle\gradlew" …"
	  exited with code 1.

Update `apksigner.csproj` to reference `java-source-utils.csproj`,
extending the "sequential order" of `gradlew`-using projects.
This should make the Windows build more reliable.

Additionally, move the `<Target/>`s out of `apksigner.csproj` and
into `apksigner.targets`.  This is more consistent with other
projects, and reduces the likelihood of VSMac rewriting (and removing
the formatting of) `apksigner.csproj`.
@jonpryor jonpryor merged commit 2197a45 into dotnet:main Jun 30, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Jan 24, 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