Skip to content

Conversation

@jonpryor
Copy link
Contributor

@jonpryor jonpryor commented Oct 26, 2017

We are investigating building Xamarin.Android atop
Visual Studio Team System (VSTS) in addition to our current Jenkins
setup, and one of the issues we're running into is "bootstrapping":
VSTS is configured to create a "fresh" VM for each build.

Pro: It should allow builds to be more reliable, as previous build
artifacts won't be present, and thus won't cause/hide errors.

Con: Previous build artifacts are not present. Previous build
artifacts such as downloading and extracting the Android NDK & SDK,
using brew to install dependencies, building MXE...

Ensuring that the dependencies are installed through make prepare
can be quite time consuming. What we want is a way to ensure that the
"build image" -- what's already installed when the VM boots --
contains all of our desired dependencies.

Furthermore, we don't want to have the responsible parties checkout
and build xamarin-android in order to determine what the dependencies
should be.

Attempt to square this circle by adding a new
make prepare-image-dependencies target, which processes
@(AndroidSdkItem), @(AndroidNdkItem), @(AntItem), and
@(RequiredProgram) to create a prepare-image-dependencies.sh
script which will download and install the required dependencies.

The generated shell script does not take the state of the machine
running make prepare-image-dependencies into consideration. This
allows the target to be executed on one machine, and the output run
on another.

    $ make prepare-image-dependencies
    # creates `prepare-image-dependencies.sh`

Note: make prepare-image-dependencies does not currently deal
with MXE. (Building MXE on the VSTS VM is very time consuming, so
it's something we need to take care of. It is not yet dealt with.)

@akoeplinger
Copy link
Member

I'd call it prepare-dependencies as it could be used for other things than just running on an image.

@jonpryor
Copy link
Contributor Author

make prepare-dependencies is an interesting idea, but we already have a make prepare-deps target -- for "dependencies"! -- so this would be confusing.

How does make prepare-image-dependencies sound?

@akoeplinger
Copy link
Member

@jonpryor not sure why we need image in the name, maybe make dependencies-script ? though I feel we're bikeshedding so whatever you prefer :)

@jonpryor jonpryor force-pushed the jonp-compile-prepare branch from b310caf to a00c6cb Compare October 26, 2017 20:33
@jonpryor jonpryor changed the title [build] Add make prepare-image target. [build] Add make prepare-image-dependencies target. Oct 26, 2017
We are investigating building Xamarin.Android atop
Visual Studio Team System (VSTS) in addition to our current Jenkins
setup, and one of the issues we're running into is "bootstrapping":
VSTS is configured to create a "fresh" VM for each build.

**Pro**: It should allow builds to be more reliable, as previous build
artifacts won't be present, and thus won't cause/hide errors.

**Con**: *Previous build artifacts are not present*. Previous build
artifacts such as *downloading and extracting* the Android NDK & SDK,
using `brew` to install dependencies, building MXE...

Ensuring that the dependencies are installed through `make prepare`
can be quite time consuming. What we want is a way to ensure that the
"build image" -- *what's already installed* when the VM boots --
contains all of our desired dependencies.

Furthermore, we *don't* want to have the responsible parties checkout
and build xamarin-android in order to determine what the dependencies
should be.

Attempt to square this circle by adding a new
`make prepare-image-dependencies` target, which processes
`@(AndroidSdkItem)`, `@(AndroidNdkItem)`, `@(AntItem)`, and
`@(RequiredProgram)` to create a `prepare-image-dependencies.sh`
script which will download and install the required dependencies.

The generated shell script does *not* take the state of the machine
running `make prepare-image-dependencies` into consideration. This
allows the target to be executed on one machine, and the output run
on another.

	$ make prepare-image-dependencies
	# creates `prepare-image-dependencies.sh`

*Note*: `make prepare-image-dependencies` does not currently deal
with MXE.  (Building MXE on the VSTS VM is *very* time consuming, so
it's something we need to take care of. It is not *yet* dealt with.)
@jonpryor jonpryor force-pushed the jonp-compile-prepare branch from a00c6cb to 39f47b2 Compare October 26, 2017 20:36
@jonpryor jonpryor merged commit aa9b33a into dotnet:master Oct 27, 2017
Redth pushed a commit to Redth/xamarin-android that referenced this pull request Oct 30, 2017
We are investigating building Xamarin.Android atop
Visual Studio Team System (VSTS) in addition to our current Jenkins
setup, and one of the issues we're running into is "bootstrapping":
VSTS is configured to create a "fresh" VM for each build.

**Pro**: It should allow builds to be more reliable, as previous build
artifacts won't be present, and thus won't cause/hide errors.

**Con**: *Previous build artifacts are not present*. Previous build
artifacts such as *downloading and extracting* the Android NDK & SDK,
using `brew` to install dependencies, building MXE...

Ensuring that the dependencies are installed through `make prepare`
can be quite time consuming. What we want is a way to ensure that the
"build image" -- *what's already installed* when the VM boots --
contains all of our desired dependencies.

Furthermore, we *don't* want to have the responsible parties checkout
and build xamarin-android in order to determine what the dependencies
should be.

Attempt to square this circle by adding a new
`make prepare-image-dependencies` target, which processes
`@(AndroidSdkItem)`, `@(AndroidNdkItem)`, `@(AntItem)`, and
`@(RequiredProgram)` to create a `prepare-image-dependencies.sh`
script which will download and install the required dependencies.

The generated shell script does *not* take the state of the machine
running `make prepare-image-dependencies` into consideration. This
allows the target to be executed on one machine, and the output run
on another.

	$ make prepare-image-dependencies
	# creates `prepare-image-dependencies.sh`

*Note*: `make prepare-image-dependencies` does not currently deal
with MXE.  (Building MXE on the VSTS VM is *very* time consuming, so
it's something we need to take care of. It is not *yet* dealt with.)
jonpryor added a commit that referenced this pull request May 6, 2022
Changes: dotnet/java-interop@2a882d2...843f3c7

  * dotnet/java-interop@843f3c78: [Java.Base-Tests] Use $(UtilityOutputFullPath)/jcw-gen.dll (#979)
  * dotnet/java-interop@4787e017: [Java.Base-Tests] Test Java-to-Managed invocations for Java.Base (#975)
  * dotnet/java-interop@59716252: [build] `main` *conceptually* targets .NET 7 (#978)
  * dotnet/java-interop@61cdb40d: [generator] Fix reserved keywords binary search (#977)
jonpryor added a commit that referenced this pull request May 6, 2022
Changes: dotnet/java-interop@2a882d2...843f3c7

  * dotnet/java-interop@843f3c78: [Java.Base-Tests] Use $(UtilityOutputFullPath)/jcw-gen.dll (#979)
  * dotnet/java-interop@4787e017: [Java.Base-Tests] Test Java-to-Managed invocations for Java.Base (#975)
  * dotnet/java-interop@59716252: [build] `main` *conceptually* targets .NET 7 (#978)
  * dotnet/java-interop@61cdb40d: [generator] Fix reserved keywords binary search (#977)
@github-actions github-actions bot locked and limited conversation to collaborators Feb 4, 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.

4 participants