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

Make xabuild smarter in configuration detection #671

Merged
merged 1 commit into from
Jun 28, 2017

Conversation

grendello
Copy link
Contributor

xabuild determines the XA installation prefix by looking at the bin/{Debug,
Release} directories, in the specified order. If one wants to build a project in
the Release configuration and both bin/Debug and bin/Release are present,
xabuild will use bin/Debug as the prefix regardless of the configuration
passed to {ms,x}build with /p:Configuration=Name. Your project will still be
built in the specified configuration but XA assemblies etc will come from the
Debug build of XA - probably not the desired outcome. To work around it you
would need to invoke xabuild as follows:

CONFIGURATION=Release xabuild /p:Configuration=Release my.csproj

which is unnecessarily verbose. This commit makes xabuild slightly smarter by
making it understand the /p:Configuration parameter and extracting the
configuration name from it and setting CONFIGURATION to this value for you.
This is done only if CONFIGURATION is not set when invoking xabuild

@@ -160,6 +160,14 @@ function ConfigureLocalXbuild()
done
}

if [ -z "$CONFIGURATION" ]; then
for p in "$*"; do
Copy link
Member

Choose a reason for hiding this comment

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

why is this indenting by two tab stops?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Emacs? :)

if [ -z "$CONFIGURATION" ]; then
for p in "$*"; do
case $p in
/p:Configuration=*|-p:Configuration=*) CONFIGURATION="`echo $p | cut -d '=' -f 2`" ;;
Copy link
Member

Choose a reason for hiding this comment

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

One problem with this is that people might not use Debug or Release configurations. For example, they could add a new Android-Debug configuration (e.g. if the solution has iOS projects as well, and they don't want to build iOS stuff when doing Android stuff), in which case CONFIGURATION would be set to Android-Debug, which would fail "weirdly" elsewhere.

If we move this logic to be before line 44, when $prefix and $Paths_targets are set, then it should be fine (-ish?), as the [ -d "$prefix/../../bin/$c" ] check on line 50 would prevent use of "invalid" CONFIGURATION values.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought about the "invalid" configurations and considered restricting the check on line 166 to just Release and Debug but then I thought that if they pass /p:Configuration=AndroidDebug then no change to the current behavior will be done, since CONFIGURATION will be set to AndroidDebug and since such directory doesn't exist at $prefix, the behavior will be unchanged wrt to the current one (it will simply continue to look for Debug and Release)

@grendello grendello force-pushed the make-xabuild-smarter branch from b9097cd to 46daed4 Compare June 27, 2017 14:58
@jonpryor
Copy link
Member

I still believe that the /p:Configuration parsing needs to occur before line 44.

At present, $CONFIGURATION is only set after $prefix and $Paths_targets has been set. Consequently:

$ xabuild /p:Configuration=Release Project.csproj

would still use a $prefix of bin/Debug, as $prefix is set on line 59, while $CONFIGURATION isn't updated until line 166.

This PR would thus be a no-op, AFAICT.

if [ -z "$CONFIGURATION" ]; then
for p in "$*"; do
case $p in
/property:Configuration=*|/p:Configuration=*|-p:Configuration=*|--property:Configuration=*) CONFIGURATION="`echo $p | cut -d '=' -f 2`" ;;
Copy link
Member

Choose a reason for hiding this comment

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

I would prefer it if this were spread across multiple lines:

			/property:Configuration=*|/p:Configuration=*|-p:Configuration=*|--property:Configuration=*)
				CONFIGURATION="`echo $p | cut -d '=' -f 2`"
				;;

This makes it easier for me to read without horizontal scrolling.

`xabuild` determines the XA installation prefix by looking at the bin/{Debug,
Release} directories, in the specified order. If one wants to build a project in
the `Release` configuration and both `bin/Debug` and `bin/Release` are present,
`xabuild` will use `bin/Debug` as the prefix regardless of the configuration
passed to `{ms,x}build` with `/p:Configuration=Name`. Your project will still be
built in the specified configuration but XA assemblies etc will come from the
`Debug` build of XA - probably not the desired outcome. To work around it you
would need to invoke `xabuild` as follows:

   CONFIGURATION=Release xabuild /p:Configuration=Release my.csproj

which is unnecessarily verbose. This commit makes `xabuild` slightly smarter by
making it understand the `/p:Configuration` parameter and extracting the
configuration name from it and setting `CONFIGURATION` to this value for you.
This is done *only* if `CONFIGURATION` is not set when invoking `xabuild`
@grendello grendello force-pushed the make-xabuild-smarter branch from 46daed4 to 2781b42 Compare June 28, 2017 14:29
@jonpryor jonpryor merged commit 91e0ba7 into dotnet:master Jun 28, 2017
@grendello grendello deleted the make-xabuild-smarter branch June 28, 2017 15:02
jonpryor pushed a commit that referenced this pull request Jun 26, 2020
Changes: dotnet/java-interop@1de5501...60efc99

Fixes: dotnet/java-interop#639
Fixes: dotnet/java-interop#664

  * dotnet/java-interop@60efc99: Update to NUnit 3.12/etc. (#667)
  * dotnet/java-interop@de35d29: [jnimarshalmethod-gen] support methods with 14+ arguments (#670)
  * dotnet/java-interop@fd2c94e: [generator] Mark protected types nested in sealed classes as private (#672)
  * dotnet/java-interop@11b7f85: [Java.Interop+MonoAndroid] Remove NullableAttributes.cs, avoid CS0436 (#671)
  * dotnet/java-interop@ef1d37b: [tools] Add response file support (#665)
  * dotnet/java-interop@1383981: [logcat-parse] Support the Android 10 `logcat` format (#663)
@github-actions github-actions bot locked and limited conversation to collaborators Feb 2, 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