Add XADebug and XARelease configurations. #41

atsushieno · 2016-05-31T07:06:37Z

It is for xamarin-android integration to set correct build output
paths.

It is for xamarin-android integration to set correct build output paths.

jonpryor · 2016-05-31T14:07:55Z

I thought I had a commit about this somewhere, but I can't find it.

Regardless, historical background: Java.Interop started as a "pie-in-the-sky what can happen if we change some fundamental starting points," and the API grew organically. Part of this was the lack of Java.Lang.Object, and instead Java.Interop.JavaObject is the "root" object of the type system, and Java.Interop.JavaException is the root for Exception types instead of Java.Lang.Throwable. (The idea being that Java.Lang.Object could become "normal", and JavaObject would have the core logic.)

Suffice it to say, the "normal" Debug/Release configurations had lots of stuff in it.

Then came Cycle 7 and a desire to fix Bug 32126, which had already been solved in Java.Interop. This introduced a desire to use Java.Interop within Xamarin.Android, but Java.Interop was "too big"; there was too much stuff to sanely pull in.

Thus the XAIntegrationDebug and XAIntegrationRelease configurations: these would be subsets of the "normal"/"full" API for use with Xamarin.Android. Notably lacking is Java.Interop.JavaObject, lifetime management, generic marshaling, and a slew of other features.

jonpryor · 2016-05-31T14:13:13Z

Regarding this PR, I don't like the idea of adding XADebug and XARelease configurations because it leads to 6 configurations per project.

As per the comment in the gist, what I'd prefer is for Java.Interop to follow xamarin-android in having a Configuration.props/Configuration.Override.props pair, <Import/>ed by all relevant projects.

This would allow xamarin-android make prepare to generate Configuration.Override.props and change the output path for the projects to something within the xamarin-android tree, without needing to add new configurations everywhere.

jonpryor · 2016-05-31T14:19:21Z

One added point: for a "full" Xamarin.Android SDK, more projects need to be referenced from Java.Interop by Xamarin.Android.sln and build into $prefix/lib/mandroid:

tools/class-parse
tools/logcat-parse
tools/generator (handled in this PR)

This is in part why I'd prefer using a Configuration.props-driven strategy, as these plus dependent projects will also need to be added to Xamarin.Android.sln.

@atsushieno

For proper use, the [xamarin-android][xa] build needs to place various Java.Interop utilities such as class-parse.exe and generator.exe into `$prefix/lib/mandroid`, so that Xamarin.Android.Build.Tasks.dll will properly verify the installation environment. There are three ways this could be accomplished: 1. The `xamarin-android` Makefile could explicitly build these utilities and override `$(OutputPath)`: xbuild external/Java.Interop/tools/class-parse /p:OutputPath=`pwd`/bin/$(CONFIGURATION)/lib/mandroid The problem with this is that we want to have the xamarin-android build system rely on MSBuild as much as possible, and this approach, while workable, runs counter to those desires. 2. We could add additional project configurations to control where the output directory should be. This was suggested by [@atsushieno][pr41]. My concern with this approach is that it's not easily extensible: it's not just a few projects that need to place files into `$prefix/lib/mandroid`, but all of their dependencies as well. Such an approach would thus require adding lots of new configurations to lots of projects. 3. Java.Interop could adopt a `xamarin-android`-style `Configuration.props` system. This would allow xamarin-android to *generate* a `Configuration.Override.props` file to specify the correct output path for those utilities. (3) is the chosen solution. It allows adding e.g. `external/Java.Interop/tools/generator/generator.csproj` to `Xamarin.Android.sln`, allowing it to be built "normally" from the `xamarin-android` build system, while causing the built files to be placed into e.g. `xamarin-android/bin/Debug/lib/mandroid` instead of the less useful `xamarin-android/external/Java.Interop/bin/Debug`. [xa]: https://github.com/xamarin/xamarin-android/ [pr41]: dotnet#41

@atsushieno

For proper use, the [xamarin-android][xa] build needs to place various Java.Interop utilities such as class-parse.exe and generator.exe into `$prefix/lib/mandroid`, so that Xamarin.Android.Build.Tasks.dll will properly verify the installation environment. There are three ways this could be accomplished: 1. The `xamarin-android` Makefile could explicitly build these utilities and override `$(OutputPath)`: xbuild external/Java.Interop/tools/class-parse /p:OutputPath=`pwd`/bin/$(CONFIGURATION)/lib/mandroid The problem with this is that we want to have the xamarin-android build system rely on MSBuild as much as possible, and this approach, while workable, runs counter to those desires. 2. We could add additional project configurations to control where the output directory should be. This was suggested by [@atsushieno][pr41]. My concern with this approach is that it's not easily extensible: it's not just a few projects that need to place files into `$prefix/lib/mandroid`, but all of their dependencies as well. Such an approach would thus require adding lots of new configurations to lots of projects. 3. Java.Interop could adopt a `xamarin-android`-style `Configuration.props` system. This would allow xamarin-android to *generate* a `Configuration.Override.props` file to specify the correct output path for those utilities. (3) is the chosen solution. It allows adding e.g. `external/Java.Interop/tools/generator/generator.csproj` to `Xamarin.Android.sln`, allowing it to be built "normally" from the `xamarin-android` build system, while causing the built files to be placed into e.g. `xamarin-android/bin/Debug/lib/mandroid` instead of the less useful `xamarin-android/external/Java.Interop/bin/Debug`. [xa]: https://github.com/xamarin/xamarin-android/ [pr41]: dotnet#41

@atsushieno

For proper use, the [xamarin-android][xa] build needs to place various Java.Interop utilities such as class-parse.exe and generator.exe into `$prefix/lib/mandroid`, so that Xamarin.Android.Build.Tasks.dll will properly verify the installation environment. There are three ways this could be accomplished: 1. The `xamarin-android` Makefile could explicitly build these utilities and override `$(OutputPath)`: xbuild external/Java.Interop/tools/class-parse /p:OutputPath=`pwd`/bin/$(CONFIGURATION)/lib/mandroid The problem with this is that we want to have the xamarin-android build system rely on MSBuild as much as possible, and this approach, while workable, runs counter to those desires. 2. We could add additional project configurations to control where the output directory should be. This was suggested by [@atsushieno][pr41]. My concern with this approach is that it's not easily extensible: it's not just a few projects that need to place files into `$prefix/lib/mandroid`, but all of their dependencies as well. Such an approach would thus require adding lots of new configurations to lots of projects. 3. Java.Interop could adopt a `xamarin-android`-style `Configuration.props` system. This would allow xamarin-android to *generate* a `Configuration.Override.props` file to specify the correct output path for those utilities. (3) is the chosen solution. It allows adding e.g. `external/Java.Interop/tools/generator/generator.csproj` to `Xamarin.Android.sln`, allowing it to be built "normally" from the `xamarin-android` build system, while causing the built files to be placed into e.g. `xamarin-android/bin/Debug/lib/mandroid` instead of the less useful `xamarin-android/external/Java.Interop/bin/Debug`. [xa]: https://github.com/xamarin/xamarin-android/ [pr41]: dotnet#41

@atsushieno

For proper use, the [xamarin-android][xa] build needs to place various Java.Interop utilities such as class-parse.exe and generator.exe into `$prefix/lib/mandroid`, so that Xamarin.Android.Build.Tasks.dll will properly verify the installation environment. There are three ways this could be accomplished: 1. The `xamarin-android` Makefile could explicitly build these utilities and override `$(OutputPath)`: xbuild external/Java.Interop/tools/class-parse /p:OutputPath=`pwd`/bin/$(CONFIGURATION)/lib/mandroid The problem with this is that we want to have the xamarin-android build system rely on MSBuild as much as possible, and this approach, while workable, runs counter to those desires. 2. We could add additional project configurations to control where the output directory should be. This was suggested by [@atsushieno][pr41]. My concern with this approach is that it's not easily extensible: it's not just a few projects that need to place files into `$prefix/lib/mandroid`, but all of their dependencies as well. Such an approach would thus require adding lots of new configurations to lots of projects. 3. Java.Interop could adopt a `xamarin-android`-style `Configuration.props` system. This would allow xamarin-android to *generate* a `Configuration.Override.props` file to specify the correct output path for those utilities. (3) is the chosen solution. It allows adding e.g. `external/Java.Interop/tools/generator/generator.csproj` to `Xamarin.Android.sln`, allowing it to be built "normally" from the `xamarin-android` build system, while causing the built files to be placed into e.g. `xamarin-android/bin/Debug/lib/mandroid` instead of the less useful `xamarin-android/external/Java.Interop/bin/Debug`. [xa]: https://github.com/xamarin/xamarin-android/ [pr41]: dotnet#41

@atsushieno

For proper use, the [xamarin-android][xa] build needs to place various Java.Interop utilities such as class-parse.exe and generator.exe into `$prefix/lib/mandroid`, so that Xamarin.Android.Build.Tasks.dll will properly verify the installation environment. There are three ways this could be accomplished: 1. The `xamarin-android` Makefile could explicitly build these utilities and override `$(OutputPath)`: xbuild external/Java.Interop/tools/class-parse /p:OutputPath=`pwd`/bin/$(CONFIGURATION)/lib/mandroid The problem with this is that we want to have the xamarin-android build system rely on MSBuild as much as possible, and this approach, while workable, runs counter to those desires. 2. We could add additional project configurations to control where the output directory should be. This was suggested by [@atsushieno][pr41]. My concern with this approach is that it's not easily extensible: it's not just a few projects that need to place files into `$prefix/lib/mandroid`, but all of their dependencies as well. Such an approach would thus require adding lots of new configurations to lots of projects. 3. Java.Interop could adopt a `xamarin-android`-style `Configuration.props` system. This would allow xamarin-android to *generate* a `Configuration.Override.props` file to specify the correct output path for those utilities. (3) is the chosen solution. It allows adding e.g. `external/Java.Interop/tools/generator/generator.csproj` to `Xamarin.Android.sln`, allowing it to be built "normally" from the `xamarin-android` build system, while causing the built files to be placed into e.g. `xamarin-android/bin/Debug/lib/mandroid` instead of the less useful `xamarin-android/external/Java.Interop/bin/Debug`. [xa]: https://github.com/xamarin/xamarin-android/ [pr41]: dotnet#41

@atsushieno

For proper use, the [xamarin-android][xa] build needs to place various Java.Interop utilities such as class-parse.exe and generator.exe into `$prefix/lib/mandroid`, so that Xamarin.Android.Build.Tasks.dll will properly verify the installation environment. There are three ways this could be accomplished: 1. The `xamarin-android` Makefile could explicitly build these utilities and override `$(OutputPath)`: xbuild external/Java.Interop/tools/class-parse /p:OutputPath=`pwd`/bin/$(CONFIGURATION)/lib/mandroid The problem with this is that we want to have the xamarin-android build system rely on MSBuild as much as possible, and this approach, while workable, runs counter to those desires. 2. We could add additional project configurations to control where the output directory should be. This was suggested by [@atsushieno][pr41]. My concern with this approach is that it's not easily extensible: it's not just a few projects that need to place files into `$prefix/lib/mandroid`, but all of their dependencies as well. Such an approach would thus require adding lots of new configurations to lots of projects. 3. Java.Interop could adopt a `xamarin-android`-style `Configuration.props` system. This would allow xamarin-android to *generate* a `Configuration.Override.props` file to specify the correct output path for those utilities. (3) is the chosen solution. It allows adding e.g. `external/Java.Interop/tools/generator/generator.csproj` to `Xamarin.Android.sln`, allowing it to be built "normally" from the `xamarin-android` build system, while causing the built files to be placed into e.g. `xamarin-android/bin/Debug/lib/mandroid` instead of the less useful `xamarin-android/external/Java.Interop/bin/Debug`. [xa]: https://github.com/xamarin/xamarin-android/ [pr41]: dotnet#41

@atsushieno

For proper use, the [xamarin-android][xa] build needs to place various Java.Interop utilities such as class-parse.exe and generator.exe into `$prefix/lib/mandroid`, so that Xamarin.Android.Build.Tasks.dll will properly verify the installation environment. There are three ways this could be accomplished: 1. The `xamarin-android` Makefile could explicitly build these utilities and override `$(OutputPath)`: xbuild external/Java.Interop/tools/class-parse /p:OutputPath=`pwd`/bin/$(CONFIGURATION)/lib/mandroid The problem with this is that we want to have the xamarin-android build system rely on MSBuild as much as possible, and this approach, while workable, runs counter to those desires. 2. We could add additional project configurations to control where the output directory should be. This was suggested by [@atsushieno][pr41]. My concern with this approach is that it's not easily extensible: it's not just a few projects that need to place files into `$prefix/lib/mandroid`, but all of their dependencies as well. Such an approach would thus require adding lots of new configurations to lots of projects. 3. Java.Interop could adopt a `xamarin-android`-style `Configuration.props` system. This would allow xamarin-android to *generate* a `Configuration.Override.props` file to specify the correct output path for those utilities. (3) is the chosen solution. It allows adding e.g. `external/Java.Interop/tools/generator/generator.csproj` to `Xamarin.Android.sln`, allowing it to be built "normally" from the `xamarin-android` build system, while causing the built files to be placed into e.g. `xamarin-android/bin/Debug/lib/mandroid` instead of the less useful `xamarin-android/external/Java.Interop/bin/Debug`. [xa]: https://github.com/xamarin/xamarin-android/ [pr41]: #41

jonpryor · 2016-06-08T21:06:15Z

Superseded by PR #45.

Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1: 9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (dotnet#47) bdf0158 Better support no installed JDKs on macOS (dotnet#48) 6353659 Log what is happening during path selection (dotnet#46) 3ef860b Take BUILD_NUMBER into consideration for Version sorting (dotnet#45) d3de054 Allow an optional locator to be provided to JdkInfo (dotnet#43) 917d3b3 Don't require quotes around `release` values (dotnet#41) 7427692 [tests] Unit tests for finding NDK location based on $PATH (dotnet#40) dbc517b Merge pull request dotnet#38 from jonpryor/jonp-ndk-via-path 511d580 Allow finding NDK location based on $PATH b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (dotnet#37) a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (dotnet#35) fae7e0a [tests] Remove temporary directories (dotnet#36) 07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (dotnet#34)

Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1: 9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (#47) bdf0158 Better support no installed JDKs on macOS (#48) 6353659 Log what is happening during path selection (#46) 3ef860b Take BUILD_NUMBER into consideration for Version sorting (#45) d3de054 Allow an optional locator to be provided to JdkInfo (#43) 917d3b3 Don't require quotes around `release` values (#41) 7427692 [tests] Unit tests for finding NDK location based on $PATH (#40) dbc517b Merge pull request #38 from jonpryor/jonp-ndk-via-path 511d580 Allow finding NDK location based on $PATH b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (#37) a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (#35) fae7e0a [tests] Remove temporary directories (#36) 07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (#34)

Add XADebug and XARelease configurations.

6bd22e4

It is for xamarin-android integration to set correct build output paths.

dnfclas added the cla-already-signed label May 31, 2016

jonpryor mentioned this pull request Jun 8, 2016

[build] Add support for Configuration.Override.props #45

Merged

jonpryor closed this Jun 8, 2016

github-actions bot locked and limited conversation to collaborators Apr 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add XADebug and XARelease configurations. #41

Add XADebug and XARelease configurations. #41

atsushieno commented May 31, 2016

jonpryor commented May 31, 2016

jonpryor commented May 31, 2016

jonpryor commented May 31, 2016

jonpryor commented Jun 8, 2016

Add XADebug and XARelease configurations. #41

Add XADebug and XARelease configurations. #41

Conversation

atsushieno commented May 31, 2016

jonpryor commented May 31, 2016

jonpryor commented May 31, 2016

jonpryor commented May 31, 2016

jonpryor commented Jun 8, 2016