| Category: Rust / Build system |
| Watchers: 7 |
| Star: 106 |
| Fork: 15 |
| Last update: Sep 29, 2023 |
An example of using CMake with Rust.
Try it!
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/tmp
make -j
make test -j
make doc -j
make install
cd examples
./example1
./example2
License:
The example files are released into the public domain, and the CMake modules are licensed under the zlib license (see file contents).
Results in:
make[2]: *** No rule to make target `CMakeFiles/TEST.dir/depend'. Stop.
make[1]: *** [CMakeFiles/TEST.dir/all] Error 2
make: *** [all] Error 2
That said, using ninja seems to work just fine, if you invoke cmake using:
$ cmake .. -G "Ninja"
$ ninja
[3/3] Building examples/example2
$ ./examples/example1
Hello
Not particularly fussed; I use ninja for everything anyway, but I thought I'd drop this in as a heads up.
This allows one to put CMakeLists inside the src directory for example
I ask because I'd like to use this, particularly because I'm not happy about the support of externals in cargo (build.rs "scripts" etc seem more complicated than the cmake analogue). To me it seems like a less complicated situation to have a project built using cmake that can build it's cargo dependencies using cmakes ExternalProject support instead.
But I don't want to do that if this is going to be adandoned. :/ Perhaps I need to just drink the punch.
My rustc (v1.3.0) appends a .d suffix to the deps file if it's not present; my build fails because of this, without this patch.
The former regexp captured next lines as well, causing corruption of CMakeCache.txt.
Hi!
There is a multilanguage project that cries out for CMake, and Rust is one of them, but I would save ourselves from using muliple flavors of make. (Note that I am not the author of the Rust sources, I am just responsible for holding the project together. There are several developers, each responsible for one language.)
There is a manybody-rust-common.rs crate that holds common functionality for all executables, one being parsing arguements using getopts. Then there are multiple executables manybody-rust-v0, v1, v2, etc. that use this common crate.
What is the best way to compile this? In a C/C++ world I would compile manybody-rust-common to a dynamic or static library and link to it. The author of the Rust sources is a Rust newbie and has a hard time answering what Cargo and rustc under the hood are doing (which I do not blame him for, as Rust on Windows is not trivial). He came up with the following Cargo script:
[package]
name = "manybody"
version = "0.0.1"
authors = ["Email here"]
[[bin]]
name = "manybody0"
path = "src/manybody0.rs"
[[bin]]
name = "manybody1"
path = "src/manybody1.rs"
...
[dependencies]
getopts = "*"
This compiles just fine. Trying to build this with CMake, I came up with the following script using the RustCMake module for the common part:
project (manybody-rust-common)
set (Project_Base_Dir ../../manybody/)
set (CMAKE_USE_RELATIVE_PATH "true")
set (Files_SRCS)
set (Files_SRCS ${Project_Base_Dir}/src/comp_phys_common.rs)
set (Files_BUILD ${Files_SRCS})
# Create filters for IDEs
source_group ("Sources" FILES ${Files_SRCS})
# Get the dependencies of all the crates
get_rust_deps(${Files_SRCS} manybody-rust-common_DEPS COMPILE)
# Build the library
rust_crate(${Files_SRCS}
ALL
TARGET_NAME ${PROJECT_NAME}
DESTINATION lib/${CONFIGURATION_NAME})
DEPENDS "${manybody-rust-common_DEPS}")
And this is the script for the v0 executable:
project (manybody-rust-v0)
set (Project_Base_Dir ../../manybody/)
set (CMAKE_USE_RELATIVE_PATH "true")
set (Files_SRCS)
set (Files_SRCS ${Project_Base_Dir}/src/manybody0.rs)
set (Files_BUILD ${Files_SRCS})
# Create filters for IDEs
source_group ("Sources" FILES ${Files_SRCS})
# Get the dependencies of all the crates
get_rust_deps(${Files_SRCS} manybody-rust-v0_DEPS)
# Build examples
rust_crate(${Files_SRCS}
ALL
TARGET_NAME ${PROJECT_NAME}
DESTINATION bin/${CONFIGURATION_NAME}
DEPENDS "${manybody-rust-common_FULL_TARGET};${manybody-rust-v0_DEPS}")
However when I try to build my project, this is what I get:
C:/Users/nagy-_000/Git/comp-phys/manybody/rust/cmake/common/../../manybody//src/comp_phys_common.rs:32:37: 32:53 error: use of undeclared type name `getopts::Options`
C:/Users/nagy-_000/Git/comp-phys/manybody/rust/cmake/common/../../manybody//src/comp_phys_common.rs:32 fn print_usage(program: &str, opts: getopts::Options) {
^~~~~~~~~~~~~~~~
C:/Users/nagy-_000/Git/comp-phys/manybody/rust/cmake/common/../../manybody//src/comp_phys_common.rs:42:20: 42:41 error: failed to resolve. Could not find `Options` in `getopts`
C:/Users/nagy-_000/Git/comp-phys/manybody/rust/cmake/common/../../manybody//src/comp_phys_common.rs:42 let mut opts = getopts::Options::new();
^~~~~~~~~~~~~~~~~~~~~
C:/Users/nagy-_000/Git/comp-phys/manybody/rust/cmake/common/../../manybody//src/comp_phys_common.rs:42:20: 42:41 error: unresolved name `getopts::Options::new`
C:/Users/nagy-_000/Git/comp-phys/manybody/rust/cmake/common/../../manybody//src/comp_phys_common.rs:42 let mut opts = getopts::Options::new();
^~~~~~~~~~~~~~~~~~~~~
error: aborting due to 3 previous errors
NMAKE : fatal error U1077: 'C:\Kellekek\Open-Source\Rust\1.0.0-beta\bin\rustc.exe' : return code '0x65'
Stop.
NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft\Visual Studio\14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft\Visual Studio\14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
Rust is a hell of a language with enormous potential, but I detest how strongly the means of compiling and distributing Rust interacts with the language itself. #pragma lib() is the evil counterpart to this in C++. Source code should have nothing to do with how I want to compile an application. Source code should not contain filenames, neither should a build system depend on directory structure or file naming conventions. It seems Rust has taken a direction where it is getting harder and harder to compile Rust without Cargo. Why should I, a package maintainer (so to say) have to learn a whole new make language just because it goes hand-in-hand with a language? Rust is not born into vacuum, and I think the community should focus more on Rust integrating with other tools, such as the VS Add-In, and RustCMake. If not promote, at least mention them on rust-lang.org.
