diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-flatdata-generator.spec | 368 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 370 insertions, 0 deletions
@@ -0,0 +1 @@ +/flatdata-generator-0.4.5.tar.gz diff --git a/python-flatdata-generator.spec b/python-flatdata-generator.spec new file mode 100644 index 0000000..b0b1e9e --- /dev/null +++ b/python-flatdata-generator.spec @@ -0,0 +1,368 @@ +%global _empty_manifest_terminate_build 0 +Name: python-flatdata-generator +Version: 0.4.5 +Release: 1 +Summary: Generate source code for C++, Rust, Go or Python from a Flatdata schema file +License: Apache Software License +URL: https://github.com/heremaps/flatdata +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/9d/9a/1746ddf70b3933e59251eb8f5fc8f623d17861face1af291fe9b5a6d8e11/flatdata-generator-0.4.5.tar.gz +BuildArch: noarch + +Requires: python3-pyparsing +Requires: python3-jinja2 + +%description +# flatdata-generator + +[](https://travis-ci.com/heremaps/flatdata/) + +Generates code from a [flatdata](https://github.com/heremaps/flatdata) schema file. + +For more information on `flatdata` and its implementations, please [refer to flatdata's homepage](https://github.com/heremaps/flatdata). + +## Using `flatdata-generator` + +```sh +# installation +pip3 install flatdata-generator + +# example: generate a header-only C++ library +flatdata-generator -s locations.flatdata -g cpp -O locations.hpp +``` + +Currently supported target languages: + +* C++ +* Rust +* Python +* Go +* Dot (graph of the schema) +* Flatdata (normalized stable schema) + +## Architecture + +### Stages + +The `flatdata` generator works in several stages which are clearly separated from one another and can be extended/tested in isolation: + +1. **Parse the source schema** file using `pyparsing` library. Grammar + for the schema is defined in `grammar.py` +2. **Construct a node tree** out of `pyparsing.ParseResults`. The node tree + contains entities for every construct of flatdata grammar, organized + in hierarchical order, allowing non-tree references between nodes: + + - `Namespace` - Nesting namespaces in the tree is allowed. + - `Structure` - Structures are grouping together a set of fields. + - `Archive` - Archives are grouping together resources and are + referencing structures or other archives (see `Reference`) + - `ResourceBase` - All resources derive from `ResourceBase` + - `Reference` - All references between flatdata entities are + modeled with `Reference` nodes. All references participate in + name resolution. There are two type of references: + - `RuntimeReference` - model explicit references and bound + resources that show themselves at runtime. + - `TypeReference` - model type dependencies, which are used during + topological sorting at a later stage and for schema resolution. + +3. **Augment the tree** with structures and references that are not + directly corresponding to `pyparsing.ParseResults` or needed to + implement advanced features. Among these: + + - **Add builtin structures** if any of the resources require them. For + example, `multivector< N, ... >` requires + `_builtin.multivector.IndexTypeN` to be available. + - **Add constant references** to all archives so that constants are + available for schema resolution. + +4. **Resolve references** iterates through all references and tries to + find a node they refer to, either in: + + - Parent scopes until (inclusive) innermost parent namespace. + - Root node if path is fully qualified. + +5. **Perform topological sorting** to detect cycles in between entities + and to determine the order of serialization for targets that depend + on one. + +6. **Generate the source code** using nodes in topological order *and/or* + the tree (depending on the generator architecture - recursive descent + or iterative). + +### Node Tree + +Every node of the tree consists of its name, properties (metadata) and +holds references to its children. Every node is reachable via certain +path which is a dot-joint concatenation of the names of its parents. +Node tree enforces several properties of the flatdata schema: + +- *No conflicting declarations*: No two nodes with the same path are + allowed. +- *All references are correct*: All reference nodes are resolvable. +- *No cyclic dependencies among resources*: All `TypeReference` + participate in topological sorting of the DAG formed by the tree + edges and edges between source and target of a `TypeReference` + +### References + +Reference names are mangled so they are not ambiguous with other paths +components. For example reference to type `T` would have name `@T`, +and similarly reference to `.foo.bar.T` would change to +`@@foo@bar@T`. + + + + +%package -n python3-flatdata-generator +Summary: Generate source code for C++, Rust, Go or Python from a Flatdata schema file +Provides: python-flatdata-generator +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-flatdata-generator +# flatdata-generator + +[](https://travis-ci.com/heremaps/flatdata/) + +Generates code from a [flatdata](https://github.com/heremaps/flatdata) schema file. + +For more information on `flatdata` and its implementations, please [refer to flatdata's homepage](https://github.com/heremaps/flatdata). + +## Using `flatdata-generator` + +```sh +# installation +pip3 install flatdata-generator + +# example: generate a header-only C++ library +flatdata-generator -s locations.flatdata -g cpp -O locations.hpp +``` + +Currently supported target languages: + +* C++ +* Rust +* Python +* Go +* Dot (graph of the schema) +* Flatdata (normalized stable schema) + +## Architecture + +### Stages + +The `flatdata` generator works in several stages which are clearly separated from one another and can be extended/tested in isolation: + +1. **Parse the source schema** file using `pyparsing` library. Grammar + for the schema is defined in `grammar.py` +2. **Construct a node tree** out of `pyparsing.ParseResults`. The node tree + contains entities for every construct of flatdata grammar, organized + in hierarchical order, allowing non-tree references between nodes: + + - `Namespace` - Nesting namespaces in the tree is allowed. + - `Structure` - Structures are grouping together a set of fields. + - `Archive` - Archives are grouping together resources and are + referencing structures or other archives (see `Reference`) + - `ResourceBase` - All resources derive from `ResourceBase` + - `Reference` - All references between flatdata entities are + modeled with `Reference` nodes. All references participate in + name resolution. There are two type of references: + - `RuntimeReference` - model explicit references and bound + resources that show themselves at runtime. + - `TypeReference` - model type dependencies, which are used during + topological sorting at a later stage and for schema resolution. + +3. **Augment the tree** with structures and references that are not + directly corresponding to `pyparsing.ParseResults` or needed to + implement advanced features. Among these: + + - **Add builtin structures** if any of the resources require them. For + example, `multivector< N, ... >` requires + `_builtin.multivector.IndexTypeN` to be available. + - **Add constant references** to all archives so that constants are + available for schema resolution. + +4. **Resolve references** iterates through all references and tries to + find a node they refer to, either in: + + - Parent scopes until (inclusive) innermost parent namespace. + - Root node if path is fully qualified. + +5. **Perform topological sorting** to detect cycles in between entities + and to determine the order of serialization for targets that depend + on one. + +6. **Generate the source code** using nodes in topological order *and/or* + the tree (depending on the generator architecture - recursive descent + or iterative). + +### Node Tree + +Every node of the tree consists of its name, properties (metadata) and +holds references to its children. Every node is reachable via certain +path which is a dot-joint concatenation of the names of its parents. +Node tree enforces several properties of the flatdata schema: + +- *No conflicting declarations*: No two nodes with the same path are + allowed. +- *All references are correct*: All reference nodes are resolvable. +- *No cyclic dependencies among resources*: All `TypeReference` + participate in topological sorting of the DAG formed by the tree + edges and edges between source and target of a `TypeReference` + +### References + +Reference names are mangled so they are not ambiguous with other paths +components. For example reference to type `T` would have name `@T`, +and similarly reference to `.foo.bar.T` would change to +`@@foo@bar@T`. + + + + +%package help +Summary: Development documents and examples for flatdata-generator +Provides: python3-flatdata-generator-doc +%description help +# flatdata-generator + +[](https://travis-ci.com/heremaps/flatdata/) + +Generates code from a [flatdata](https://github.com/heremaps/flatdata) schema file. + +For more information on `flatdata` and its implementations, please [refer to flatdata's homepage](https://github.com/heremaps/flatdata). + +## Using `flatdata-generator` + +```sh +# installation +pip3 install flatdata-generator + +# example: generate a header-only C++ library +flatdata-generator -s locations.flatdata -g cpp -O locations.hpp +``` + +Currently supported target languages: + +* C++ +* Rust +* Python +* Go +* Dot (graph of the schema) +* Flatdata (normalized stable schema) + +## Architecture + +### Stages + +The `flatdata` generator works in several stages which are clearly separated from one another and can be extended/tested in isolation: + +1. **Parse the source schema** file using `pyparsing` library. Grammar + for the schema is defined in `grammar.py` +2. **Construct a node tree** out of `pyparsing.ParseResults`. The node tree + contains entities for every construct of flatdata grammar, organized + in hierarchical order, allowing non-tree references between nodes: + + - `Namespace` - Nesting namespaces in the tree is allowed. + - `Structure` - Structures are grouping together a set of fields. + - `Archive` - Archives are grouping together resources and are + referencing structures or other archives (see `Reference`) + - `ResourceBase` - All resources derive from `ResourceBase` + - `Reference` - All references between flatdata entities are + modeled with `Reference` nodes. All references participate in + name resolution. There are two type of references: + - `RuntimeReference` - model explicit references and bound + resources that show themselves at runtime. + - `TypeReference` - model type dependencies, which are used during + topological sorting at a later stage and for schema resolution. + +3. **Augment the tree** with structures and references that are not + directly corresponding to `pyparsing.ParseResults` or needed to + implement advanced features. Among these: + + - **Add builtin structures** if any of the resources require them. For + example, `multivector< N, ... >` requires + `_builtin.multivector.IndexTypeN` to be available. + - **Add constant references** to all archives so that constants are + available for schema resolution. + +4. **Resolve references** iterates through all references and tries to + find a node they refer to, either in: + + - Parent scopes until (inclusive) innermost parent namespace. + - Root node if path is fully qualified. + +5. **Perform topological sorting** to detect cycles in between entities + and to determine the order of serialization for targets that depend + on one. + +6. **Generate the source code** using nodes in topological order *and/or* + the tree (depending on the generator architecture - recursive descent + or iterative). + +### Node Tree + +Every node of the tree consists of its name, properties (metadata) and +holds references to its children. Every node is reachable via certain +path which is a dot-joint concatenation of the names of its parents. +Node tree enforces several properties of the flatdata schema: + +- *No conflicting declarations*: No two nodes with the same path are + allowed. +- *All references are correct*: All reference nodes are resolvable. +- *No cyclic dependencies among resources*: All `TypeReference` + participate in topological sorting of the DAG formed by the tree + edges and edges between source and target of a `TypeReference` + +### References + +Reference names are mangled so they are not ambiguous with other paths +components. For example reference to type `T` would have name `@T`, +and similarly reference to `.foo.bar.T` would change to +`@@foo@bar@T`. + + + + +%prep +%autosetup -n flatdata-generator-0.4.5 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-flatdata-generator -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Fri May 05 2023 Python_Bot <Python_Bot@openeuler.org> - 0.4.5-1 +- Package Spec generated @@ -0,0 +1 @@ +615f0914bfef3139a8524baf555c64f0 flatdata-generator-0.4.5.tar.gz |