-
Notifications
You must be signed in to change notification settings - Fork 537
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
Conversation
tools/scripts/xabuild
Outdated
@@ -160,6 +160,14 @@ function ConfigureLocalXbuild() | |||
done | |||
} | |||
|
|||
if [ -z "$CONFIGURATION" ]; then | |||
for p in "$*"; do |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Emacs? :)
tools/scripts/xabuild
Outdated
if [ -z "$CONFIGURATION" ]; then | ||
for p in "$*"; do | ||
case $p in | ||
/p:Configuration=*|-p:Configuration=*) CONFIGURATION="`echo $p | cut -d '=' -f 2`" ;; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
)
b9097cd
to
46daed4
Compare
I still believe that the At present,
would still use a This PR would thus be a no-op, AFAICT. |
tools/scripts/xabuild
Outdated
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`" ;; |
There was a problem hiding this comment.
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`
46daed4
to
2781b42
Compare
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)
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 bothbin/Debug
andbin/Release
are present,xabuild
will usebin/Debug
as the prefix regardless of the configurationpassed to
{ms,x}build
with/p:Configuration=Name
. Your project will still bebuilt 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 youwould need to invoke
xabuild
as follows:CONFIGURATION=Release xabuild /p:Configuration=Release my.csproj
which is unnecessarily verbose. This commit makes
xabuild
slightly smarter bymaking it understand the
/p:Configuration
parameter and extracting theconfiguration name from it and setting
CONFIGURATION
to this value for you.This is done only if
CONFIGURATION
is not set when invokingxabuild