I recently had some problems with configuring dependencies (like openssl) and rpath/frameworks dependencies for macos. Both of those were solved but required help from outside scripts.
So the question is simple - is it a good/viable idea to add build-pre.rs and build-post.rs in addition to build.rs?
build-pre.rs - will run before any dependencies and add ability to set env variables and such build-post.rs - will run after the build, allowing to perform some actions on the final binary
Or mybe adding other entry points to build.rs except main. Something like fn main_pre_build() and fn main_post_build()
Hi,
from my experience you could also use cargo-make and provide a simple makefile that will perform all the pre/post steps as well as the cargo build of your project. This way you do not pollute the current build system or require enhancements of the build.rs behaviour. And you are a bit more flexible from my point of view.
I think Cargo should have first-class built-in support for building dynamic libraries, with correct rpath, sover, etc. Fixing these problems shouldn't be left to every user to find out the hard way and patch themselves in a custom platform-specific way.
As for openssl dependency, it is a major PITA, but installation of openssl is typically done system-wide. I wouldn't want random Rust dependencies to mess with my operating system. Installation of a wrong version of openssl could break the whole system.
What do you mean by installing or messing with the system?
In my project I use prebuilt static openssl library that I need to use in my project (not installed in the system). Problem is that openssl crate requires env variables to configure where libraries are located and which version (static/shared) to use.
In which ways are makefiles more flexible than actual rust code running in the build.rs?
Also I don't see how making build process more configurable this way is polluting anything. Its not like I'm asking to add something completely different from what we currently have. The only difference is when actual function is run.
Well, without knowing the exact details that you are planning to put into a build-pre.rs and a build-post.rs to support specific actions during your build process, I thought I could propose an existing solution/possibility where to store your pre/post execution steps - assuming they already exists - instead of waiting for a cargo/rust feature that might not be available soon.
With cargo-make and a proper make file you could also use rust code if I remember the docs correctly to facilitate pre- and post- build steps combined with the general and runs-as-usual cargo build of your project.
I agree that needing to set env variables is a pain, and Cargo needs a better system for configuration beyond feature booleans.
However, a pre-build Rust script wouldn't be able to set the env variables for its parent. They'd be gone when it the script ends, just like it happens with build.rs.
The openssl crate has a vendored feature if you just need a static build, without customizations.
Question was only about improving rust in general, not asking for help at this time. I've already resolved my problems with the help of external shell scripts.