| ▲ | zokier 6 days ago |
| I was under the impression that macros can execute arbitrary code, surely some FP would not be big problem. And if not macros then build.rs script certainly could do the trick. |
|
| ▲ | dhosek 6 days ago | parent [-] |
| build.rs can definitely execute arbitrary code, which means that a lot of places (including, IIRC crates.io) will forbid crates that rely on build.rs. I ended up refactoring my build.rs into a separate sub-application in finl_unicode that built data tables which are then checked into git and used pre-built. I include the sub-app in the source code so that anyone with access to the repo could continue development if I were to die tomorrow. |
| |
| ▲ | n_plus_1_acc 6 days ago | parent [-] | | There are many crates with build.rs scripts on crates.io, because they host just the source code with the Cargo.{toml,lock}. | | |
| ▲ | dhosek 6 days ago | parent [-] | | I ran into some issues with crates.io and my build.rs when I first released the crate, although it’s long enough ago, that I don’t remember exactly what the issue was. It might also have been that the build.rs script downloaded raw data files from unicode.org | | |
| ▲ | Arnavion 6 days ago | parent [-] | | crates.io doesn't care what your build.rs does because it doesn't try to compile your code, neither now or ever in the past. There would be no point in it trying to compile your code; there are lots of crates that are bindings to C libraries that crates.io's builders can't be expected to have, crates that target architectures which crates.io can't be expected to have builders for, etc. |
|
|
|
