You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
*Rebuilding* API-O (571546a) results in a build failure:
# First build is fine:
$ make framework-assemblies API_LEVELS=26 CONFIGURATIONS=Debug
# Second+ builds are not:
$ make framework-assemblies API_LEVELS=26 CONFIGURATIONS=Debug
...
obj/Debug/android-26/mcw/Android.Content.IComponentCallbacks.cs(23,17): error CS0101: The namespace 'Android.Content' already contains a definition for 'IComponentCallbacksInvoker'
...
170582 Error(s)
The cause of the build error is that
`Android.Content.IComponentCallbacks.cs` -- among many other files --
*is* specified twice (!):
* obj/Debug/android-26/mcw//Android.Content.IComponentCallbacks.cs
* full/path/to/…/xamarin-android/src/Mono.Android/obj/Debug/android-26/mcw//Android.Content.IComponentCallbacks.cs
This in turn is related to 98880bd: There are two "environments" in
which `Mono.Android.csproj` is built:
* A "clean" environment
* A previously built environment
In the clean environment, `Mono.Android.projitems` -- created by
`generator.exe` in the `_GenerateBinding` target -- does not exist.
Consequently, after `generator.exe` is run, all of the generated
`$(IntermediateOutputPath)\**\*.cs` files are added to `@(Compile)` so
that the compiler will "see" all of the generated files and things
will build.
In the previously built environment, `Mono.Android.projitems` *does*
exist, and is `<Import/>`ed. The `_GenerateBinding` target is
*skipped*, "preventing" the `@(Compile)` group from being updated to
contain the generated files -- which is desirable, because those files
are already listed in `Mono.Android.projitems`, and including them
would result in "duplicating" the files provided to the compiler.
Note that the `_GenerateBinding` target depends on the
`_GenerateApiDescription` target, so that when
`_GenerateApiDescription` creates an `api.xml` file, then
`_GenerateBinding` will *re-execute*.
This is where API-O rebuilds go wrong:
1. This is a previously built environment, so
`Mono.Android.projitems` (1) exists, and (2) is `<Import/>`ed.
2. The `_GenerateApiDescription` always executes (!).
3. (2) results in `_GenerateBinding` always executing, causing the
`@(Compile)` group to be updated, resulting filenames being
provided to the compiler *twice*.
(2) is where things go bad:
Target _GenerateApiDescription needs to be built as input file 'Profiles/api-26.xml.in' does not exist.
Specifically, `_GenerateApiDescription` listed as an `Input` the file
`Profiles\api-$(AndroidApiLevel).xml.in`. However, commit 571546a
named the API-O binding `Profiles\api-O.xml.in`, meaning
`Profiles\api-26.xml.in` does not exist, *and won't exist* (until
API-26 is actually released as "stable" by Google, at some unknown
point in the future).
Which is why API-O rebuilds fail. :-)
The fix? Don't use `$(AndroidApiLevel)`, use `$(AndroidPlatformId)`.
For API-O, `$(AndroidPlatformId)` will have the value "O", allowing
`Profiles\api-O.xml.in` to be found, preventing
`_GenerateApiDescription` from unnecessarily executing.
---
This scenario *does* raise a potential (unresolved) workflow problem:
when:
1. `Mono.Android.csproj` is built, and
2. `Profiles\api-*.xml.in` is modified, and
3. `Mono.Android.csproj` is built again,
then everything will break in the same manner as described here:
`Mono.Android.projitems` will exist, thus adding generated files to
`@(Compile)`, then the `_GenerateApiDescription` & `_GenerateBinding`
targets will execute, re-adding files to `@(Compile)`, and things will
break.
A subsequent rebuild will "fix" the error, so long as a
`Profiles\api-*.xml.in` file isn't modified, but this will be annoying
to anyone who encounters it.
0 commit comments