My current development environment is VSCode on Windows, using rust-analyzer for code analysis, running tests and debug builds on Windows, and running release builds on WSL.
I want to begin using blessed crate https://diesel.rs with a MySQL backend. The 'Getting Started' page has reasonable instructions for Linux, given that I mainly need to install libmysqlclient on top of other dependencies usually present for compiling programs (after installing mysql and setting it up), and then I can include diesel in my Cargo.toml file. I can isolate the dependency using a feature, but I don't want to exclude the feature on Windows targets, because rust-analyzer builds for Windows to see if I have compilation errors.
I have not yet gotten it to work on Windows at all. Installation is more complicated: the dependency mysqlclient-sys has a build script dependent on environment variables, which were not set by the MySQL installer on Windows, and it isn't clear from the script's error message which are not set correctly. Diesel's instructions recommend a bundled mysqlclient-sys but this fails in building openssl-sys because perl is not installed in the Windows environment. I had to search for answers to these problems because the documentation didn't address it, and some threads were years old and out of date. And finally, getting diesel_cli to build via cargo install in PowerShell does not imply that building will succeed in VSCode, as that's the current status of my Windows setup.
Discussion:
I really like the crate ecosystem and ease-of-use in adding dependencies to my project. This is really the first time I can think of that a crate has a dependency on something I haven't already installed, and it's been a uniquely frustrating experience that I can't spend my time focusing on writing code and testing out the new dependency.
Is there Could there be a way to allow this dependency management to occur within the cargo files, such as:
specifying config values in an environment file, similar to how dotenvy reads from a .env file? (and having cargo build request them if they're missing)
specifying and checking requirements that cannot be installed by cargo or build scripts, such as perl
Ideally I also don't have to provide in-depth installation instructions for diesel stuff beyond MySQL, just as diesel shouldn't have to for mysqlclient-sys, and just as mysqlclient-sys shouldn't have to for openssl-sys. (MySQL table setup can easily be scripted.)
My project has no reason to be platform-specific, so it would feel bad to ditch Windows as an allowed target platform. But on the other hand, having a streamlined build process is such a core feature of cargo that it also feels bad to have these issues trying to add a popular crate as a dependency for multiple popular platforms.
I don't know what's going on here, but you might have better luck asking in users.rust-lang.org. That forum is for providing people help with using Rust, this forum is for discussions about features of the Rust language and how we can improve it.
The individual issue has already been resolved. I'm using it as an example of a gap in my cargo experience in order to start a discussion around how to improve it.
Maybe I should reword "Is there a way" to "Could there be a way"
The system-deps crate might be heading a nicer direction for the whole ecosystem, and has been adopted by quite a few crates, but it seems there's still a long way to go.
I just would like to leave this as note here: While system-deps sounds like a great solution it has some important restrictions which make it hard to use it as general solution. It's based on pkg-config, which means it will work well on most linux based systems. Unfortunately that also means it won't work well in other setups like systems using windows or custom linux configurations or cross compiling setups. That makes it really hard to use it a solution if you need to support these other setups as well.
In general finding system dependencies is really messy and needs a lot of custom configurations so support widely different system configurations and requirements, especially on windows. As far as I'm aware there cannot be a cross platform way to declare this users just have "too much" control over where to put stuff and the whole system did grow organically over the last ~30 years or something like that.
pkg-config also performs (previously performed?) the dubious action of patching how cmake performs certain loads/resolutions, which doesn't work with all dependencies....
I think solutions like that systemically underestimate complexity of the problem.
OSes with package management (like Linux distros) do a lot of work for you to clean and normalize all the weird libraries, their quirks, incompatibilities, bizarre requirements, etc.
Then the problem looks like "just" picking the right library location and a few flags, so you may be fooled into thinking it can't be so hard.
But in every other environment that hasn't already done the work of building a whole OS worth of packages that work together – it's not a matter of "just" finding the libraries, it's a difficulty on the same scale of complexity as building an operating system distro, with all the ugly package-specific hairy mess that happens behind the scenes now being your problem, multiplied by every package by every target OS.
I think it's not an accident that Rust crates have bespoke build scripts:
if you support 1 package on O number of operating systems, like build.rs scripts to, this is 1xO problem size, which is manageable.
if you support 1 operating system with P packages, you have 1xP work to do, which is a lot, but a distro can do most of it for you, so for distro-centric system-deps/metabuild/pkg-config it feels like 1x1 problem.
if you try to make system-deps that works on more than just existing package managers, you suddenly have PxO sized problem, and no help. That's not realistic, which is why these tools are chronically bad on Windows and macOS, and/or try hard to delegate the hard work to the most Linux-distro-like thing they can get, like macOS Homebrew.