-
Notifications
You must be signed in to change notification settings - Fork 564
[build] Add make prepare-image-dependencies target.
#979
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
Conversation
2ad55fc to
b310caf
Compare
|
I'd call it |
|
How does |
|
@jonpryor not sure why we need |
b310caf to
a00c6cb
Compare
make prepare-image target.make prepare-image-dependencies target.
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.)
a00c6cb to
39f47b2
Compare
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.)
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)
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)
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
brewto install dependencies, building MXE...Ensuring that the dependencies are installed through
make preparecan 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-dependenciestarget, which processes@(AndroidSdkItem),@(AndroidNdkItem),@(AntItem), and@(RequiredProgram)to create aprepare-image-dependencies.shscript which will download and install the required dependencies.
The generated shell script does not take the state of the machine
running
make prepare-image-dependenciesinto consideration. Thisallows the target to be executed on one machine, and the output run
on another.
Note:
make prepare-image-dependenciesdoes not currently dealwith 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.)