-
Notifications
You must be signed in to change notification settings - Fork 560
[Xamarin.Android.Build.Tasks] dx.jar command line too long. #888
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
build |
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=59651 We were passing ALL the .class files in as parameters to the dx.jar invocation. Turns out we can just pass the top level directory. In this case `$(IntermediateOutputPath)android\bin\classes` will do fine. Because its a directory dx will pick up any .class file it finds in any subdirectory. I did try this with the .jar files as well, but because allot of the libraries have a `lib` folder which contain a internal .jar file it causes problems. This is because it produces dupicate types. So rather than specificly ignore the lib folder (which migth change) we will just stick to the current system.
e98f78c
to
8cea0a2
Compare
Nooooooo. You broke the core part of the changes. It does NOT work with d8.jar while it does work with dx.jar. |
@atsushieno then we need a different fix. since providing a huge command line breaks a simple XF app on windows. |
Well, it breaks building Xamarin.Forms itself on VS2017, yep. That'll block XF from upgrading from VS2015. |
@atsushieno what we probably need to do is zip all the .class files up and pass the zip file to |
Sounds like we need tests which use both |
Did the zip work fix move forward? |
@kingces95: I do not understand the question. |
The PR broke something and the proposed work around was to zip up the files passed to the tool instead of enumerating them one by one. So I was wondering if any progress was made on that solution. I ask because we're cutting a VS2017 solution for forms and without this fix then we'll fail to build when we upgrade. |
@kingces95 I am looking at the zip solution, its just an idea at this point. I should have some time to work on it next week though. |
@kingces95 PR is up for the zip solution. #911 |
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=59651 We were passing ALL the `.class` files in as parameters to the `dx.jar` invocation. Turns out we can just pass the top level directory. In this case `$(IntermediateOutputPath)android\bin\classes` will do fine. Because it's a directory `dx` will pick up any `.class` file it finds in any subdirectory. I did try this with the `.jar` files as well, but because a lot of the libraries have a `lib` folder which contain an internal `.jar` file it causes problems. This is because it produces duplicate types. So rather than specifically ignore the `lib` folder (which might change) we will just stick to the current system.
Context: dotnet/java-interop@846f211 Changes: dotnet/java-interop@c936d09...7c8d463 * dotnet/java-interop@7c8d4638: [build] Fix -t:Prepare on Linux (#892) * dotnet/java-interop@41ba3485: [tests] Add net6.0 TargetFramework. (#888) * dotnet/java-interop@403dd37a: [class-parse] Ignore .jnilib files within .jar files (#890) * dotnet/java-interop@bda6be43: [class-parse] Add support for some JDK-11 constant pool types (#889) * dotnet/java-interop@4277ac96: Bump to xamarin/xamarin-android-tools/main@34e98e2b (#887) * dotnet/java-interop@846f2116: [generator] Remove buggy annotation loose match (#886) Commit dotnet/java-interop@846f2116 made our annotation support more accurate, which had a side-effect of introducing changes to generated custom attributes. Update `tests/api-compatibility/acceptable-breakages*.txt` to deal with the fallout from dotnet/java-interop@846f2116.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=59651
We were passing ALL the .class files in as parameters to the
dx.jar invocation. Turns out we can just pass the top level
directory. In this case
$(IntermediateOutputPath)android\bin\classes
will do fine. Because its a directory dx will pick up any
.class file it finds in any subdirectory.
I did try this with the .jar files as well, but because allot
of the libraries have a
lib
folder which contain a internal .jarfile it causes problems. This is because it produces dupicate types.
So rather than specificly ignore the lib folder (which migth change)
we will just stick to the current system.