Generate api-*.xml.in on the fly, using class-parse and api-xml-adjuster. #1038
Conversation
This file contains hidden or 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
atsushieno
force-pushed
the
generate-api-xml-on-demand
branch
2 times, most recently
from
8b26a8f to
0596eab
Compare
atsushieno
added a commit
to atsushieno/xamarin-android
that referenced
this pull request
Nov 21, 2017
api-*.xml.in can be generated dynamically (up to [*1]) but enumification helper tools still depended on DroidDoc, meaning that we cannot remove package download dependencies. This fixes the situation by eliminating the dependencies. Especially it is easier to just parse api-*.xml.in to extract int consts from Java API. ... thought so? It turnd out to not be that easy. Unlike DroidDoc, api-*.xml.in does not contain "api-since" information, so we need to parse ALL the API XML. And they cannot be **precise** because we only have a subset of the API definitions. For example, "since API Level 1" now becomes "since API Level 10" because we don't have api-1.xml.in (not even api-4.xml.in). So they will become non-precise. (A slightly better possibility to "fix" this is to parse `android-sdk-whatever/platform-tools/api/api-versions.xml`, but it won't contain "already vanished" constants so it will be incomplete either. I didn't bother to do "better" so far. We don't need that for enumification.) Therefore, there is a lot of changes in `map.csv` to reflect those "insignificant" changes to remap "API since" column (e.g. from "1" to "10"). Regeneration from api-LEVEL.xml.in instead of DroidDoc has some other side effects; some consts are back to the list so that we don't have to manually copy existing mapped consts that could not be generated from the latest DroidDocs (due to disappearance) anymore. Instead we have to remove manually-mapped constants (either from the sources or `map.csv`). Therefore, a handful of heading lines in `map.csv` were removed, and some definitions in `enum-conversion-mappings.xml` are back. [*1] dotnet#1038
atsushieno
added a commit
to atsushieno/xamarin-android
that referenced
this pull request
Nov 30, 2017
api-*.xml.in can be generated dynamically (up to [*1]) but enumification helper tools still depended on DroidDoc, meaning that we cannot remove package download dependencies. This fixes the situation by eliminating the dependencies. Especially it is easier to just parse api-*.xml.in to extract int consts from Java API. ... thought so? It turnd out to not be that easy. Unlike DroidDoc, api-*.xml.in does not contain "api-since" information, so we need to parse ALL the API XML. And they cannot be **precise** because we only have a subset of the API definitions. For example, "since API Level 1" now becomes "since API Level 10" because we don't have api-1.xml.in (not even api-4.xml.in). So they will become non-precise. (A slightly better possibility to "fix" this is to parse `android-sdk-whatever/platform-tools/api/api-versions.xml`, but it won't contain "already vanished" constants so it will be incomplete either. I didn't bother to do "better" so far. We don't need that for enumification.) Therefore, there is a lot of changes in `map.csv` to reflect those "insignificant" changes to remap "API since" column (e.g. from "1" to "10"). Regeneration from api-LEVEL.xml.in instead of DroidDoc has some other side effects; some consts are back to the list so that we don't have to manually copy existing mapped consts that could not be generated from the latest DroidDocs (due to disappearance) anymore. Instead we have to remove manually-mapped constants (either from the sources or `map.csv`). Therefore, a handful of heading lines in `map.csv` were removed, and some definitions in `enum-conversion-mappings.xml` are back. [*1] dotnet#1038
atsushieno
force-pushed
the
generate-api-xml-on-demand
branch
from
0596eab to
d252623
Compare
atsushieno
added a commit
to atsushieno/xamarin-android
that referenced
this pull request
Nov 30, 2017
api-*.xml.in can be generated dynamically (up to [*1]) but enumification helper tools still depended on DroidDoc, meaning that we cannot remove package download dependencies. This fixes the situation by eliminating the dependencies. Especially it is easier to just parse api-*.xml.in to extract int consts from Java API. ... thought so? It turnd out to not be that easy. Unlike DroidDoc, api-*.xml.in does not contain "api-since" information, so we need to parse ALL the API XML. And they cannot be **precise** because we only have a subset of the API definitions. For example, "since API Level 1" now becomes "since API Level 10" because we don't have api-1.xml.in (not even api-4.xml.in). So they will become non-precise. (A slightly better possibility to "fix" this is to parse `android-sdk-whatever/platform-tools/api/api-versions.xml`, but it won't contain "already vanished" constants so it will be incomplete either. I didn't bother to do "better" so far. We don't need that for enumification.) Therefore, there is a lot of changes in `map.csv` to reflect those "insignificant" changes to remap "API since" column (e.g. from "1" to "10"). Regeneration from api-LEVEL.xml.in instead of DroidDoc has some other side effects; some consts are back to the list so that we don't have to manually copy existing mapped consts that could not be generated from the latest DroidDocs (due to disappearance) anymore. Instead we have to remove manually-mapped constants (either from the sources or `map.csv`). Therefore, a handful of heading lines in `map.csv` were removed, and some definitions in `enum-conversion-mappings.xml` are back. [*1] dotnet#1038
atsushieno
added a commit
to atsushieno/xamarin-android
that referenced
this pull request
Nov 30, 2017
api-*.xml.in can be generated dynamically (up to [*1]) but enumification helper tools still depended on DroidDoc, meaning that we cannot remove package download dependencies. This fixes the situation by eliminating the dependencies. Especially it is easier to just parse api-*.xml.in to extract int consts from Java API. ... thought so? It turnd out to not be that easy. Unlike DroidDoc, api-*.xml.in does not contain "api-since" information, so we need to parse ALL the API XML. And they cannot be **precise** because we only have a subset of the API definitions. For example, "since API Level 1" now becomes "since API Level 10" because we don't have api-1.xml.in (not even api-4.xml.in). So they will become non-precise. (A slightly better possibility to "fix" this is to parse `android-sdk-whatever/platform-tools/api/api-versions.xml`, but it won't contain "already vanished" constants so it will be incomplete either. I didn't bother to do "better" so far. We don't need that for enumification.) Therefore, there is a lot of changes in `map.csv` to reflect those "insignificant" changes to remap "API since" column (e.g. from "1" to "10"). Regeneration from api-LEVEL.xml.in instead of DroidDoc has some other side effects; some consts are back to the list so that we don't have to manually copy existing mapped consts that could not be generated from the latest DroidDocs (due to disappearance) anymore. Instead we have to remove manually-mapped constants (either from the sources or `map.csv`). Therefore, a handful of heading lines in `map.csv` were removed, and some definitions in `enum-conversion-mappings.xml` are back. [*1] dotnet#1038
atsushieno
force-pushed
the
generate-api-xml-on-demand
branch
from
d252623 to
87b6a3b
Compare
|
The latest version "builds". But it runs builds class-parse and api-xml-adjuster unnecessarily many times. MSBuild is stupid and lame. It failed to design appropriate and consistent way to describe Inputs and Outputs because it is hacky addon feature. I didn't bother to fix that issue, I'm not the one who introduced MSBuild on our build system. Whoever fanboys MSBuild can fix that. |
atsushieno
added a commit
to atsushieno/xamarin-android
that referenced
this pull request
Dec 1, 2017
api-*.xml.in can be generated dynamically (up to [*1]) but enumification helper tools still depended on DroidDoc, meaning that we cannot remove package download dependencies. This fixes the situation by eliminating the dependencies. Especially it is easier to just parse api-*.xml.in to extract int consts from Java API. ... thought so? It turnd out to not be that easy. Unlike DroidDoc, api-*.xml.in does not contain "api-since" information, so we need to parse ALL the API XML. And they cannot be **precise** because we only have a subset of the API definitions. For example, "since API Level 1" now becomes "since API Level 10" because we don't have api-1.xml.in (not even api-4.xml.in). So they will become non-precise. (A slightly better possibility to "fix" this is to parse `android-sdk-whatever/platform-tools/api/api-versions.xml`, but it won't contain "already vanished" constants so it will be incomplete either. I didn't bother to do "better" so far. We don't need that for enumification.) Therefore, there is a lot of changes in `map.csv` to reflect those "insignificant" changes to remap "API since" column (e.g. from "1" to "10"). Regeneration from api-LEVEL.xml.in instead of DroidDoc has some other side effects; some consts are back to the list so that we don't have to manually copy existing mapped consts that could not be generated from the latest DroidDocs (due to disappearance) anymore. Instead we have to remove manually-mapped constants (either from the sources or `map.csv`). Therefore, a handful of heading lines in `map.csv` were removed, and some definitions in `enum-conversion-mappings.xml` are back. [*1] dotnet#1038
atsushieno
force-pushed
the
generate-api-xml-on-demand
branch
from
87b6a3b to
5e515da
Compare
…ter. It helps API generator changes more robust by running API generation consistently with unit testing.
atsushieno
force-pushed
the
generate-api-xml-on-demand
branch
from
5e515da to
931682d
Compare
|
It's left unmerged for too long time. |
|
Merging as per "one week without any comments" policy. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It helps API generator changes more robust by running API generation
consistently with unit testing.