Build.rs: s-exp -> rust?

  1. Question: Is there an example of a build.rs that converts s-expr's into plain Rust code ?

  2. Please note, the above question asks: "Is X possible?" Please refrain from debating "Is X a good idea?" "Why would you want to do X?" "Should we fork Rust to support X?"

===

In a separate thread, I saw this:

Question here is: has anyone managed to create a build.rs which converts s-exprs to Rust ?

Ignore garbage collection / scheme semantics for now. Imagine we have a language that has Rust semantics, but merely chose to adopt s-exprs as the syntax. Is build.rs something that could take a directory full of src/*.s-expr and generate a virtual directory of src/*.rs which is then compiled ?

1 Like

bindgen is a way to generate Rust code that binds to C code.

This build.rs example for bindgen is the closest thing to what you are asking for that I am aware of.

build.rs can run whatever you want. So if you want to run a transpiler in it, you certainly can.

There's probably not an example of doing it specifically (since it's not particularly useful) but it's just putting pieces together. It's no different from generating code based on interface definition files or whatever.

Interesting, so this code basically

  1. for every foo.h

  2. generates foo.rs

  3. C struct -> Rust struct, and C func decl -> Rust extern c func decl

That's it right? So basically this is just a change of the '.h -> .rs' to '.s-expr -> .rs'.

More or less. As the next page of the tutorial I linked before shows, if you use the OUT_DIR then you need to include the generated files in order to have them be compiled.

But if you want to, you can write directly to the /src directory. As @scottmcm mentioned, you can essentially do whatever you want.

This probably won't work when the crate is used as a dependency, however.

Good point.

If the code generation is best done on every build then OUT_DIR would be the way to go.

If the code generation is best done ahead of time, only by the crate maintainer(s), then some code that ran outside of the build process would probably be better. For example a shell script or a task defined using xtask.

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.