ritual
ritual copied to clipboard
Use gcc crate instead of cmake?
Right now cmake is required for building the lib generated by cpp_to_rust
an alternative would be to use the gcc crate instead which would remove the need for the user to have cmake installed.
I think it would be nice to remove dependency on cmake, but I don't want to reinvent cmake. It actually solves a lot of issues:
- It automatically builds a shared or static library from a folder of source files in a cross-platform way;
- It skips building source files that were not changed (extremely important during development);
- it allows to have parallel builds with "make -j N";
- It allows to install all headers and library files in a chosen folder easily.
All this is accomplished with a very simple config file (less than 20 lines). How much code will it take to implement the same behavior using gcc crate? How much of these features can it provide?
In the simplest form using the gcc crate is this
// build.rs
extern crate gcc;
fn main() {
gcc::compile_library("libfoo.a", &["foo.c", "bar.c"]);
}
- The gcc crate uses rayon to build in parallel also and uses the correct compiler given the version of Rust (if MSVC on Windows it will build the code using MSVC etc)
- Also for a user of a crate they will very rarely change the code inside the crate they just want to build the crate by adding a dependency in their project.
- You can pick any folder to have the files for the gcc crate also.
- Unsure about incremental. Yet this isn't important for a crate user as the will build the crate and don't touch it again.
But MSVC libraries are *.lib, not *.a. Also it seems that this crate doesn't support shared libraries, only static ones. I need shared libraries for MSVC because it can't compile them statically (too many symbols).
The gcc crate uses *.a even for msvc. I have used this in several projects and it works just fine. I have never ran into the issue with too many symbols on msvc so unsure about that.
Actually, this feature would be useful even if it doesn't cover all use cases. We can leave cmake as default option and fallback to gcc crate if cmake is not available and there are no other issues.
Sounds good!