add readmes and so on

typeshare2/typeshare-main/Cargo.toml → typeshare2/typeshare-driver/Cargo.toml

@@ -1,5 +1,5 @@
 [package]
-name = "typeshare-main"
+name = "typeshare-driver"
 version = "0.1.0"
 edition = "2021"
 

typeshare2/typeshare-driver/README.md

@@ -0,0 +1,18 @@
+# typeshare-driver
+
+This crate contains a macro generating all the glue code necessary to create a typeshare binary. The idea is that person wanting a typeshare binary supporting
+certain languages would be able to write something as simple as:
+
+```rust
+use typeshare_swift::Swift;
+use typeshare_typescript::Typescript;
+use typeshare_driver::generate_typeshare_cli
+
+generate_typeshare_cli!(Swift, Typescript)
+```
+
+This would create a `fn main` that uses these languages, plus `typeshare-engine`, that implements a full typeshare CLI.
+
+This crate is among the last things I want to work on, because making it sufficiently configurable might be tricky.
+
+Theoretically, if (for example) `typeshare-python` wanted to export a full `typeshare-python` binary, it could depend on both `typeshare-model` (for the implementation) and `typeshare-main` for the binary, exposing the latter probably as a cargo feature.

typeshare2/typeshare-engine/README.md

@@ -0,0 +1,17 @@
+# typeshare-engine
+
+This crate includes all of the actual implmenentations of typeshare functionality. It should be a dependency of anyone trying to USE typeshare as a library. It depends ONLY on typeshare-model, not on any language crates. It exports functions that make use of the traits in typeshare-model, so that callers can do something like this (this is just an example, not my real intended API)
+
+```rust
+use std::env::current_dir;
+use typeshare_engine::run;
+use typeshare_swift::Swift;
+
+fn main() {
+    let working_dir = current_dir();
+    let source_dir = working_dir.join("src");
+    let out_dir = working_dir.join("output");
+
+    run(source_dir, working_dir, Swift);
+}
+```