3 ms·

While yes, it can be a pain, I love that rust makes it hard to be a special snowflake. It promotes everyone following set conventions and makes it easier to gro

by demarq 10y ago

While yes, it can be a pain, I love that rust makes it hard to be a special snowflake. It promotes everyone following set conventions and makes it easier to grok other peoples work. rust's powerful macros are an exception to this, I guess.

flukus 10y ago
Is there a convention for the placement of generated code?
- ekidd 10y ago
  Yes. Cargo supports build.rs scripts that build code into a special directory reserved for code generation, IIRC. The cargo people generally think this sort of thing through.
  - flukus 10y ago
    Ok, I checked it out (http://doc.crates.io/build-script.html http://doc.crates.io/build-script.html) Would have been much better if you could tell it the dependencies instead of having to use yet another make clone (and a bad one at that) though.
    - ekidd 10y ago
      > Would have been much better if you could tell it the dependencies instead of having to use yet another make clone (and a bad one at that) though. It's not intended to be used like make, with lots of shell scripts in a Makefile. Instead, you write all the actual build code for a given task once, and package it in a Rust crate, which can then be pulled as a build-time dependency. So, for example, there's a cmake crate (https://docs.rs/cmake/0.1.20/cmake/ https://docs.rs/cmake/0.1.20/cmake/) that handles any project using cmake. If you just have one of two glue files written in C, you use the gcc crate (http://alexcrichton.com/gcc-rs/gcc/index.html http://alexcrichton.com/gcc-rs/gcc/index.html), which—despite the name—can also handle other C compilers on other platforms. And if you need to generate code for a perfect hash function, you use phf (https://docs.rs/phf_codegen/0.7.20/phf_codegen/ https://docs.rs/phf_codegen/0.7.20/phf_codegen/). And so on. If you run into some other kind of common pattern across many projects, just write and publish another crate, and call it from build.rs. These libraries typically do a lot of work to handle things like cross-platform compatibility. If you already assume the programmer (1) knows Rust, and (2) might be running on either Linux, MacOS or Windows, this sort of interface is much more convenient than requiring them to get Makefiles and shell scripts working, and to handle per-platform compiler invocation issues, etc.

by demarq 10y ago

flukus 10y ago

Is there a convention for the placement of generated code?

ekidd 10y ago
Yes. Cargo supports build.rs scripts that build code into a special directory reserved for code generation, IIRC. The cargo people generally think this sort of thing through.
- flukus 10y ago
  Ok, I checked it out (http://doc.crates.io/build-script.html http://doc.crates.io/build-script.html) Would have been much better if you could tell it the dependencies instead of having to use yet another make clone (and a bad one at that) though.
  - ekidd 10y ago
    > Would have been much better if you could tell it the dependencies instead of having to use yet another make clone (and a bad one at that) though. It's not intended to be used like make, with lots of shell scripts in a Makefile. Instead, you write all the actual build code for a given task once, and package it in a Rust crate, which can then be pulled as a build-time dependency. So, for example, there's a cmake crate (https://docs.rs/cmake/0.1.20/cmake/ https://docs.rs/cmake/0.1.20/cmake/) that handles any project using cmake. If you just have one of two glue files written in C, you use the gcc crate (http://alexcrichton.com/gcc-rs/gcc/index.html http://alexcrichton.com/gcc-rs/gcc/index.html), which—despite the name—can also handle other C compilers on other platforms. And if you need to generate code for a perfect hash function, you use phf (https://docs.rs/phf_codegen/0.7.20/phf_codegen/ https://docs.rs/phf_codegen/0.7.20/phf_codegen/). And so on. If you run into some other kind of common pattern across many projects, just write and publish another crate, and call it from build.rs. These libraries typically do a lot of work to handle things like cross-platform compatibility. If you already assume the programmer (1) knows Rust, and (2) might be running on either Linux, MacOS or Windows, this sort of interface is much more convenient than requiring them to get Makefiles and shell scripts working, and to handle per-platform compiler invocation issues, etc.