forked from dotnet/android
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Xamarin.Android.Build.Tasks] Path is too long (dotnet#700)
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=30147 Windows (still) has a max path limit of 260 characters.. This can cause us a problem if the user creates a project in a directory which already takes up most of that limit.. Like on their Desktop! This is because of the intermediate structure that was introduced to handle embedding resources into the assemblies. The current intermediate structure is as follows $(IntermediateOutputPath)\__library_project_imports__\$(AssemblyName)\library_project_imports\ $(IntermediateOutputPath)\__library_project_imports__\$(AssemblyName)\native_library_imports\ Now consider that `$(AssemblyName)` can sometimes end up with something lile "Xamarin.Android.Support.v7.AppCompat.21.0.3.0" you can easily see how we start getting into trouble. There was an attempt to fix this up a while ago (722dcc05) by introducing the `$(UseShortFileNames)` property. However while this did introduce a directory structure which was shorter is broke backwards compatability with older versions of xamarin-android. This is because of the structore of the zip files we that are embedded into the assemblies. The current system just extracts the zip into the `$(IntermediateOutputPath)\__library_project_imports__\$(AssemblyName)\` directory and assumes that it contains a `library_project_imports` directory. All the build tasks also assumed that as well. So the fix needs to be done on a number of fronts. Firstly we need to update the `$(_LibraryProjectImportsDirectoryName)` and `$(_NativeLibraryImportsDirectoryName)` to be something shorter. Next up we need to shorten "__library_project_imports__" to something else verbose as well. This should cut down on the amount of the MAX_PATH we chew up. The real key to this is to NOT change the structure of the zip files in the assemblies! So when we generate a zip from "jlibs" we make sure that the folder in the zip is called "library_project_imports". And when we extract the zip file we makle sure that "library_project_imports" is replaced by the shorter name. This will ensure that we are backward compatbile with older versions BUT more importantly we get to use the shorter directory structure. The files for native librarys are not extracted to disk but are extracted from memory so as long as the structure remains the same i.e "native_library_imports" that code does not need to change. The other thing we need to do is to update ResolveLibraryProjectImports Task to upgrade the system when it runs. So if we already have a "libraryprojectimports.cache" in place we just use that as is. But if we re-run the ResolveLibraryProjectImports task (due to a change or a clean build) we detect if we have the older structure in place and just remove it.. Since we are going to regenerate the entire cache again anyway we might as well start from scratch. With this in place it becomes possible we can now enable `$(UseShortFileNames)` by default! So the new structure that is created is as follows $(IntermediateOutputPath)\lp\<id>\jl $(IntermediateOutputPath)\lp\<id>\nl The <id> will be a single integer value which can be mapped to the source assembly via a new map.cache file. This .cache file will contain a list of assemblys. We use the `Index` of the assembly in the list to figure out which cache directory to use. UnnamedProject Library1 In this case `Library1` would have an index of `1` and `UnnamedProject` will be `0`. The old behaviour can be enabled by setting `$(UseShortFileNames)` to `False`. Note in order to keep existing bindings generator behaviour consistent, the BindingsGenerator task will not use the `$(UseShortFileNames)` property to control how it generates its .cs files. Instead a new property $(UseShortGeneratorFileNames) which can be used to control if the generator produces short names (e.g 1.cs, 2.cs). This will be `False` by default.
- Loading branch information
1 parent
7dadd00
commit 0667a2b
Showing
14 changed files
with
273 additions
and
136 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.