Add stdin/out support about frame_transpiler HOT 5 OPEN

@walkie I am actively investigating this now and interested in your perspective on how to handle this. I am thinking to follow the POSIX syntax:

• A token consisting of a single hyphen character is interpreted as an ordinary non-option argument. By convention, it is used to specify input from or output to the standard input and output streams.
  https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html

I'm also thinking that -o could be used to specify a target file.

Thoughts? Also I am just looking into structopt now so if you have guidance on how this can be easily done LMK, otherwise I'll dig in (which isn't a bad thing).

Thanks!

from frame_transpiler.

For argument parsing, you should probably use clap instead of structopt since that seems to be the standard now. The structopt docs even have a note saying that it's now in maintence mode and to use clap instead.

I don't have any strong opinion on the syntax, but following a standard seems like a 👍 to me. The other option might just be to do whatever is most natural/easiest with clap, since that's likely to follow the most common practice. (Those two options might be the same, in which case, even better!)

from frame_transpiler.

@walkie So I now think the actual proper standard is that the absence of a filename is the indicator to read from stdin. However currently framec takes the language parameter as a positional parameter, just like the filename and therefore not really distinguishable (unless I'm missing some subtlety to this).

So I'm thinking to make the language a mandatory option with value so:

framec -l rust < Spec.frm

Would this break a lot of tooling on your side?

from frame_transpiler.

We're not using the CLI at all, so it won't impact us. We call Exe::run_file directly from a build.rs file.

Only tangentially related to the issue here, but we actually have several different build.rs files floating around for different projects that all do slight variants of the same thing. I'm currently abstracting the shared behavior out, and I plan to add it to the Frame repo as a new frame_build crate. I'll add a README to that describing our pattern for integrating Frame state machines into larger Rust projects, which might be helpful for others hoping to use Frame+Rust.

I'll let you merge the PR on that one since it adds a new crate to the repo.

from frame_transpiler.

from frame_transpiler.