This repository has been archived by the owner on Mar 26, 2020. It is now read-only.
External types #95
Merged
External types #95
Conversation
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
mknejp
force-pushed
the
feature/extern-types-2
branch
from
b073149
to
f6c18af
Compare
mknejp
force-pushed
the
feature/extern-types-2
branch
from
f6c18af
to
f4021f3
Compare
|
rebased |
mknejp
force-pushed
the
feature/extern-types-2
branch
from
f4021f3
to
73de46c
Compare
|
+1 |
Marshals use the respective members to resolve typenames, signatures, parameter types etc. All names in MExtern are expected to be fully qualified.
These YAML files generated by Djinni hold all the necessary information to integrate these types with other Djinni projects, thus making (precompiled) libraries with possible. There are still limitations: - Extern enums/records cannot be used as constants as their enumerant/field information is not yet preserved. - Include paths are fixed at the point of YAML generation, including paths do Djinni's support-lib. This may require some form of placeholders, or being smart about project structure in general. Generation is controlled with following options - --yaml-out: The output folder for YAML files (Generator disabled if unspecified). - --yaml-out-file: If specified all types are merged into a single YAML file instead of generating one file per type (relative to --yaml-out). - --yaml-prefix: The prefix to add to type names stored in YAML files (default: "").
This is a demonstration that the generator can be further simplified by moving types which do not require dedicated generator magic to externally declared types.
This demonstrates some fancy template usage to provide a std::chrono::duration<rep, period> capable external type. It is mapped to NSTimeInterval and java.time.Duration. It can be used after importing "duration.yaml" as follows: - duration<i32, s> => std::chrono::duration<i32, std::ratio<1>> - duration<f64, ns> => std::chrono::duration<double, std::nano>
mknejp
force-pushed
the
feature/extern-types-2
branch
from
6b9bac2
to
b704a7c
Compare
|
rebased |
j4cbo
added a commit
that referenced
this pull request
Jul 17, 2015
Awesome. Thanks for all the rebasing!
Closed
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.
This is the implementation foreshadowed in #52 based on the latest and greatest master.
Long story short: This allows Djinni to generate YAML files for storing all the information necessary to integrate the generated types in a different project. The directive
@extern "mylib.yaml"makes the types within available to your Djinni project.These YAML files can also be created by hand and, provided with the necessary translators, allow the integration of types not generated by Djinni (e.g.
std::chrono::duration<->NSTimeInterval<->java.time.Duration).I added a section to the README and there are some examples in the test suite. One of them mimics the builtin "date" type, showing that complexity can be removed from the generators for types that don't require special magic. However that leaves the open question of how to inject these "standard" types. The other example is
duration:Something to keep in mind is the YAML file stores all the include paths as they were specified in the Djinni invocation. For some types that includes paths to the support lib, so maybe it would be wise to make a standard
includedirectory for the "standard" headers and require people to set their search paths to it.This feature does not change the output of existing stuff.