Develop resources for Rust integration with other build systems

[adamgreig]

Related to #1.

We won't block the book on this but it would be useful to develop and collate resources on integrating Rust (and Cargo) with build systems such as make and cmake. We can then include them in the interoperability chapter.

[ryankurte]

Not sure what approach we want to take with cmake, but, I wrote a function to build cargo projects ryankurte/rust-cmake that I've been trying out.

[R030t1]

The best way to integrate with other build systems is to separate the usage of rust from cargo. Language specific package managers are one of the main conflict points with Linux and BSD package management and have very real reproducibility and security impacts. See how most major distributions repackage Python code instead of using pip and the issues that caused them to do so.

Attempting to wrap an invocation of cargo is probably not the best solution. It could potentially work but it relies on all dependencies referring to system libraries as appropriate.

This would mean, at least in the context of cmake, reproducing most of the "find package" code inside of cargo or a cargo based build system. It is better to let the user handle that as appropriate or to create a way to pass that in to cargo. The user will defer to their package manager (Linux/BSD) or own best judgement (custom usecase). If neither is necessary the user is probably on Windows where there is no real package management (vcpkg may or may not fill that niche in the future) and is likely fine building everything with cargo.

I understand many rust developers and users like cargo, but realize that on platforms that already have package managers it is a major pain point. Relying on cargo is creating a lot of work for everyone that does not want to closely monitor rust and its libraries.

[ryankurte]

Attempting to wrap an invocation of cargo is probably not the best solution. It could potentially work but it relies on all dependencies referring to system libraries as appropriate.

Yeah, this is a significant problem I have been mulling over a bit in the context of https://github.com/rust-embedded/wg/issues/481 It seems we could mitigate this by providing a mechanism to ensure a *-sys package did use the system library? You still have to vet your packages, but, it could mitigate one of the causes of the repackaging-every-package conundrum.