You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 6, 2020. It is now read-only.
instead of relying on the user to implement a build script, now that cargo install is becoming a thing, it could be as easy as cargo install syntex, cargo syntex build
To figure out which files to use, maybe instead of main.rs.in one could use main.rs.syntex and translate all .syntex files.
The text was updated successfully, but these errors were encountered:
Interesting! How do you think this would work when one builds a library that uses syntex? What if cargo syntex could generate a build.rs script, and re-running it would re-generate the build.rs?
How would a cargo subcommand know what plugins to run? Syntex by itself doesn't do anything unless you register plugins for it to apply. At that point I don't see this significantly reducing the complexity compared to build.rs.
The idea is to not re-generate the files in every build, but generate them once and put them onto crates.io. This way crates using syntex won't even have to depend on syntex on crates.io
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
instead of relying on the user to implement a build script, now that
cargo install
is becoming a thing, it could be as easy ascargo install syntex
,cargo syntex build
To figure out which files to use, maybe instead of
main.rs.in
one could usemain.rs.syntex
and translate all.syntex
files.The text was updated successfully, but these errors were encountered: