trinitrix
/
trixy
Archived
5
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
This repository has been archived on 2024-05-26. You can view files and clone it, but cannot push or open issues or pull requests.
trixy/Cargo.toml

87 lines
2.4 KiB
TOML
Raw Normal View History

chore(treewide): Add the new license header
2024-02-19 15:13:06 +00:00
# Copyright (C) 2023 - 2024:
# The Trinitrix Project <soispha@vhack.eu, antifallobst@systemausfall.org>
chore(treewide): Add or update license header
2024-03-26 18:56:20 +00:00
# SPDX-License-Identifier: LGPL-3.0-or-later
#
chore(treewide): Add the new license header
2024-02-19 15:13:06 +00:00
# This file is part of the Trixy crate for Trinitrix.
#
# Trixy is free software: you can redistribute it and/or modify
# it under the terms of the Lesser GNU General Public License as
# published by the Free Software Foundation, either version 3 of
# the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# and the Lesser GNU General Public License along with this program.
# If not, see <https://www.gnu.org/licenses/>.
chore: Initial commit This not the "real" first commit, the others are in the trinitrix/core repository, made before the split-up took place
2023-12-23 15:07:17 +00:00
[package]
name = "trixy"
chore(version): v0.1.1
2024-05-04 08:26:03 +00:00
version = "0.1.1"
chore: Initial commit This not the "real" first commit, the others are in the trinitrix/core repository, made before the split-up took place
2023-12-23 15:07:17 +00:00
edition = "2021"
chore(Cargo.toml): Add further required metadata
2024-05-03 18:02:17 +00:00
description = "A rust crate used to generate multi-language apis for your application"
chore(Cargo.toml): Add required metadata
2024-05-03 17:32:44 +00:00
license = "LGPL-3.0-or-later"
repository = "https://git.nerdcult.net/trinitrix/trixy"
categories = ["config", "compilers", "development-tools::ffi"]
keywords = ["ffi", "c-ffi", "api"]
chore: Initial commit This not the "real" first commit, the others are in the trinitrix/core repository, made before the split-up took place
2023-12-23 15:07:17 +00:00
[dependencies]
refactor(treewide): Rework file structure in `src/macros` This might be a big diff, but I _hope_ that it does not change much functionally (hopefully it changes nothing generation specific). What has changed? ----------------- - I had to merge the three crates into one, to allow `macros` to impl functions on Types defined in `parser`. - As mentioned in the point above, the conversion function are now inherent to the type they convert (i. e. `r#type.to_rust()` instead of `type_to_rust(r#type)`). - The conversion function have been sorted, by what they convert to: - `to_rust()` converts a type to be used in rust *host* code. - `to_c()` converts a type to be used in c *host* code. - `to_auxiliary_c()` converts a type to be used in c *auxiliary* code. - The top-most `generate` method of `TrixyConfig` now returns a `FileTree` instead of writing the files directly. The `FileTree` can still be materialize with the `materialize` method. But this change facilitates moving non-generation focused code out of the `generate` method. What is the difference between _host_ and _auxiliary_ code? ----------------------------------------------------------- Auxiliary code is always written in the language it is generated for. So auxiliary code for c would be written in c (or at least in a subset of c), as it represents c header files. Host code is always written in rust. This is the code that is responsible for implementing the actual ffi stuff. In our case these are the `extern "C"` functions and the types, defined in trixy. The rust host code is generating the native rust representations of these types.
2024-03-26 09:38:14 +00:00
clap = { version = "4.5.4", features = ["derive"], optional = true }
style(treewide): format
2024-03-26 16:28:21 +00:00
convert_case = { version = "0.6.0", optional = true }
build(treewide): Update
2024-05-19 11:50:50 +00:00
proc-macro2 = { version = "1.0.82", optional = true }
quote = { version = "1.0.36", optional = true }
syn = { version = "2.0.64", features = [
style(treewide): format
2024-03-26 16:28:21 +00:00
"extra-traits",
"full",
"parsing",
], optional = true }
build(treewide): Update
2024-05-19 11:50:50 +00:00
thiserror = { version = "1.0.61", optional = true }
pulldown-cmark = { version = "0.11.0", optional = true }
refactor(treewide): Rework file structure in `src/macros` This might be a big diff, but I _hope_ that it does not change much functionally (hopefully it changes nothing generation specific). What has changed? ----------------- - I had to merge the three crates into one, to allow `macros` to impl functions on Types defined in `parser`. - As mentioned in the point above, the conversion function are now inherent to the type they convert (i. e. `r#type.to_rust()` instead of `type_to_rust(r#type)`). - The conversion function have been sorted, by what they convert to: - `to_rust()` converts a type to be used in rust *host* code. - `to_c()` converts a type to be used in c *host* code. - `to_auxiliary_c()` converts a type to be used in c *auxiliary* code. - The top-most `generate` method of `TrixyConfig` now returns a `FileTree` instead of writing the files directly. The `FileTree` can still be materialize with the `materialize` method. But this change facilitates moving non-generation focused code out of the `generate` method. What is the difference between _host_ and _auxiliary_ code? ----------------------------------------------------------- Auxiliary code is always written in the language it is generated for. So auxiliary code for c would be written in c (or at least in a subset of c), as it represents c header files. Host code is always written in rust. This is the code that is responsible for implementing the actual ffi stuff. In our case these are the `extern "C"` functions and the types, defined in trixy. The rust host code is generating the native rust representations of these types.
2024-03-26 09:38:14 +00:00
# macros
build(treewide): Update
2024-05-19 11:50:50 +00:00
prettyplease = { version = "0.2.20", optional = true }
refactor(treewide): Rework file structure in `src/macros` This might be a big diff, but I _hope_ that it does not change much functionally (hopefully it changes nothing generation specific). What has changed? ----------------- - I had to merge the three crates into one, to allow `macros` to impl functions on Types defined in `parser`. - As mentioned in the point above, the conversion function are now inherent to the type they convert (i. e. `r#type.to_rust()` instead of `type_to_rust(r#type)`). - The conversion function have been sorted, by what they convert to: - `to_rust()` converts a type to be used in rust *host* code. - `to_c()` converts a type to be used in c *host* code. - `to_auxiliary_c()` converts a type to be used in c *auxiliary* code. - The top-most `generate` method of `TrixyConfig` now returns a `FileTree` instead of writing the files directly. The `FileTree` can still be materialize with the `materialize` method. But this change facilitates moving non-generation focused code out of the `generate` method. What is the difference between _host_ and _auxiliary_ code? ----------------------------------------------------------- Auxiliary code is always written in the language it is generated for. So auxiliary code for c would be written in c (or at least in a subset of c), as it represents c header files. Host code is always written in rust. This is the code that is responsible for implementing the actual ffi stuff. In our case these are the `extern "C"` functions and the types, defined in trixy. The rust host code is generating the native rust representations of these types.
2024-03-26 09:38:14 +00:00
# parser
style(treewide): format
2024-03-26 16:28:21 +00:00
regex = { version = "1.10.4", optional = true }
refactor(treewide): Rework file structure in `src/macros` This might be a big diff, but I _hope_ that it does not change much functionally (hopefully it changes nothing generation specific). What has changed? ----------------- - I had to merge the three crates into one, to allow `macros` to impl functions on Types defined in `parser`. - As mentioned in the point above, the conversion function are now inherent to the type they convert (i. e. `r#type.to_rust()` instead of `type_to_rust(r#type)`). - The conversion function have been sorted, by what they convert to: - `to_rust()` converts a type to be used in rust *host* code. - `to_c()` converts a type to be used in c *host* code. - `to_auxiliary_c()` converts a type to be used in c *auxiliary* code. - The top-most `generate` method of `TrixyConfig` now returns a `FileTree` instead of writing the files directly. The `FileTree` can still be materialize with the `materialize` method. But this change facilitates moving non-generation focused code out of the `generate` method. What is the difference between _host_ and _auxiliary_ code? ----------------------------------------------------------- Auxiliary code is always written in the language it is generated for. So auxiliary code for c would be written in c (or at least in a subset of c), as it represents c header files. Host code is always written in rust. This is the code that is responsible for implementing the actual ffi stuff. In our case these are the `extern "C"` functions and the types, defined in trixy. The rust host code is generating the native rust representations of these types.
2024-03-26 09:38:14 +00:00
# types
build(treewide): Update
2024-05-19 11:50:50 +00:00
libc = { version = "0.2.155", optional = true }
style(treewide): format
2024-03-26 16:28:21 +00:00
log = { version = "0.4.21", optional = true }
refactor(treewide): Rework file structure in `src/macros` This might be a big diff, but I _hope_ that it does not change much functionally (hopefully it changes nothing generation specific). What has changed? ----------------- - I had to merge the three crates into one, to allow `macros` to impl functions on Types defined in `parser`. - As mentioned in the point above, the conversion function are now inherent to the type they convert (i. e. `r#type.to_rust()` instead of `type_to_rust(r#type)`). - The conversion function have been sorted, by what they convert to: - `to_rust()` converts a type to be used in rust *host* code. - `to_c()` converts a type to be used in c *host* code. - `to_auxiliary_c()` converts a type to be used in c *auxiliary* code. - The top-most `generate` method of `TrixyConfig` now returns a `FileTree` instead of writing the files directly. The `FileTree` can still be materialize with the `materialize` method. But this change facilitates moving non-generation focused code out of the `generate` method. What is the difference between _host_ and _auxiliary_ code? ----------------------------------------------------------- Auxiliary code is always written in the language it is generated for. So auxiliary code for c would be written in c (or at least in a subset of c), as it represents c header files. Host code is always written in rust. This is the code that is responsible for implementing the actual ffi stuff. In our case these are the `extern "C"` functions and the types, defined in trixy. The rust host code is generating the native rust representations of these types.
2024-03-26 09:38:14 +00:00
[dev-dependencies]
# parser
pretty_assertions = "1.4.0"
[features]
feat(macros/config/file_tree): Add support for parsing a FileTree from file This makes storing expected `FileTree`s as markdown possible (useful in tests).
2024-03-26 14:56:55 +00:00
# default = ["parser", "types", "macros", "build-binary"]
default = ["parser", "types", "macros"]
build-binary = ["parser", "types", "macros", "clap", "pulldown-cmark"]
refactor(treewide): Rework file structure in `src/macros` This might be a big diff, but I _hope_ that it does not change much functionally (hopefully it changes nothing generation specific). What has changed? ----------------- - I had to merge the three crates into one, to allow `macros` to impl functions on Types defined in `parser`. - As mentioned in the point above, the conversion function are now inherent to the type they convert (i. e. `r#type.to_rust()` instead of `type_to_rust(r#type)`). - The conversion function have been sorted, by what they convert to: - `to_rust()` converts a type to be used in rust *host* code. - `to_c()` converts a type to be used in c *host* code. - `to_auxiliary_c()` converts a type to be used in c *auxiliary* code. - The top-most `generate` method of `TrixyConfig` now returns a `FileTree` instead of writing the files directly. The `FileTree` can still be materialize with the `materialize` method. But this change facilitates moving non-generation focused code out of the `generate` method. What is the difference between _host_ and _auxiliary_ code? ----------------------------------------------------------- Auxiliary code is always written in the language it is generated for. So auxiliary code for c would be written in c (or at least in a subset of c), as it represents c header files. Host code is always written in rust. This is the code that is responsible for implementing the actual ffi stuff. In our case these are the `extern "C"` functions and the types, defined in trixy. The rust host code is generating the native rust representations of these types.
2024-03-26 09:38:14 +00:00
style(treewide): format
2024-03-26 16:28:21 +00:00
parser = ["regex", "thiserror", "convert_case"]
types = [
"parser",
"libc",
"log",
"proc-macro2",
"quote",
"syn",
"thiserror",
"convert_case",
]
macros = [
"parser",
"types",
"prettyplease",
"proc-macro2",
"quote",
"syn",
"convert_case",
"pulldown-cmark",
]
feat(bin): Add a binary, that helps in showing the generated code
2024-03-26 09:51:11 +00:00
[[bin]]
name = "trixy"
required-features = ["build-binary"]