Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop resources for Rust integration with other build systems #61

Open
adamgreig opened this issue Oct 23, 2018 · 3 comments
Open

Develop resources for Rust integration with other build systems #61

adamgreig opened this issue Oct 23, 2018 · 3 comments
Labels
help wanted Extra attention is needed

Comments

@adamgreig
Copy link
Member

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.

bors bot added a commit that referenced this issue Oct 23, 2018
63: Add links to interop issues r=therealprof a=adamgreig

See #61 and #62.

Co-authored-by: Adam Greig <[email protected]>
@ryankurte
Copy link

ryankurte commented Oct 25, 2018

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.

@japaric japaric added the help wanted Extra attention is needed label Nov 6, 2018
njmartin10 pushed a commit to njmartin10/book that referenced this issue Nov 10, 2018
63: Add links to interop issues r=therealprof a=adamgreig

See rust-embedded#61 and rust-embedded#62.

Co-authored-by: Adam Greig <[email protected]>
@R030t1
Copy link

R030t1 commented Aug 9, 2020

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
Copy link

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 rust-embedded/wg#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants