I have a git repository with some test code in C++ and I want to use Googletest to write some tests. I used git submodule to get it as part of the above repository. I want to use meson as the build engine. So far, so good.
However, I cannot fathom how to get meson to build and link my tests with the googletest submodule… Should I use a wrap? An external dependency? what?
Note that meson supports dependencies on packaged versions of gtest/gmock but this is not what I want since the developers of gtest/gmock recommend against it. Plus, I want bleeding edge 'cause I am crazy⸮
Furthermore, I do not think ninja plays a role here but I mentioned that I use it just in case.
I tried using the wrap for gtest with
gtest_proj = subproject('gtest')
gtest_dep = gtest_proj.get_variable('gtest_dep')
gmock_dep = gtest_proj.get_variable('gmock_dep')
in meson.build. This builds a local copies of googletest which can then be used like so:
tests_src = [
'tests/gtest-all.cpp',
'tests/test_MyClass.cpp',
]
e = executable(
'gtest-all',
tests_src,
dependencies : [
gtest_dep,
gmock_dep],
link_with : libshield,
)
test('gtest tests', e)
Note that libshield is a shared library created from my (toy) code so I can link to it.
If you would like to use a project that is not meson project you need to find that project in wrapDB:
meson wrap search gtest
If that command gives you name of the wrap then you need to install it to your project:
mkdir -p subprojects
meson wrap install gtest
Then you should reconfigure your project and meson will download that project for you:
meson --reconfigure path/to/build/dir
Additional information you can find in documentation of wrap tool.
--reconfigure - supported since 0.49.0
Related
I built a tool that requires configuration by means of a config.yaml. I'd like to provide a basic version of that file along with the installation. Is it possible to have customizable task carried out (such as creating a directory under /etc/mytool/ and creating a file herein) when running cargo install --path .?
Build Scripts are your friend.
The Rust file designated by the build command (relative to the package root) will be compiled and invoked before anything else is compiled in the package, allowing your Rust code to depend on the built or generated artifacts. By default Cargo looks up for "build.rs" file in a package root (even if you do not specify a value for build).
Use build = "custom_build_name.rs" to specify a custom build name, e.g. add in Cargo.toml:
[package]
# ...
build = "custom_build_name.rs"
I have a rust project where I want to use protobuf definitions that exist in another, non-rust repository.
I'm planning to download the protobuf repository, create a src/common_protobuf module in my main repository, use cargo build to generate all the rust implementations of each protobuf into the common_protobuf module, then selectively re-export the generated structures into their intended modules with pub use.
I can't seem to find the best way to specify the dependency. Using
[build-dependencies]
pbrepo = { git="https://github.com/username/pbrepo" }
results in
Caused by:
Could not find Cargo.toml in `/Users/username/.cargo/git/checkouts/pbrepo-33abcde7dddd6356/fdefgd9`
I can't commit a Cargo.toml into the external repository. I considered using a git submodule or making a sys-crate with the submodule and Cargo.toml but I prefer to have my build dependencies in a single place and not have to synchronize multiple repos during a build.
I could download the repository manually in the the build scripts and set the commit to pull in my build.rs but again I would like to have all my build dependencies in one place.
Is there a mechanism to accomplish this or is this a better way to use remote protobuf definitions?
Cargo does not support downloading non-Rust dependencies. The only things that you can have Cargo download for you are Cargo packages (loosely “crates”).
Even if you added a Cargo.toml to your non-Rust repository, that would not help, since there is no way to ask for the location of that dependency to read from it. Cargo's dependencies mechanism lets you depend on a built library only, not its source files (as far as I know; I could have missed something).
You will have to use some separate procedure that downloads the dependency (custom script, git submodule…) before running cargo build.
I'd use cargo-make
It allows for more complex dependency tracking and building things from other languages.
Since you can't use Cargo directly, you have to resort to a higher-level mechanism, such as Git submodules, which can be downloaded automatically before building via build.rs. This way cargo build will both fetch the submodule and build your project in a single command.
According to Ethereum Developers' Guide:
You can build all code using the go tool, placing the resulting binary
in $GOPATH/bin.
go install -v ./...
What does ./... do in the context of:
go install -v ./...
That will install any "main" packages found in the current or subdirectories,
"subdirectories": that is what the ./... syntax means.
It forces go install to consider not just the current folder/package ('.'), but also the ones in the sub-folders: "..."
See "What is a sensible way to layout a Go project": you can have multiple packages "main", in a library driven development:
Moving the main.go file out of your root allows you to build your application from the perspective of a library. Your application binary is simply a client of your application’s library.
Sometimes you might want users to interact in multiple ways so you create multiple binaries.
For example, if you had an “adder” package that that let users add numbers together, you may want to release a command line version as well as a web version.
You can easily do this by organizing your project like this:
adder/
adder.go
cmd/
adder/
main.go
adder-server/
main.go
Users can install your “adder” application binaries with “go get” using an ellipsis:
$ go get github.com/benbjohnson/adder/...
And voila, your user has “adder” and “adder-server” installed!
Similarly, a go install -v ./... would install “adder” and “adder-server” as well.
Note: the -v print the names of packages as they are compiled.
I need to use rapidjson as a third party library to replace libjson. I'm trying to figure out how to build it so I can use it's build files in my project (dependency list).
I downloaded rapidjson from github, and I'm trying to get a buildable project. I'm looking at the instructions at rapidjson website, and it's showing that I need to do the following, below (Installation).
We don't use git, so what would I need to do instead of the git submodule update --init step?
Why would I need a build dir in the include/rapidjson directory with nothing in it?
When I cd to build and type cmake, it seems to be missing parameters. What is the full cmake command? Thanks!
Installation
RapidJSON is a header-only C++ library. Just copy the include/rapidjson folder to system or project's include path.
RapidJSON uses following software as its dependencies:
•CMake as a general build tool
•(optional)Doxygen to build documentation
•(optional)googletest for unit and performance testing
To generate user documentation and run tests please proceed with the steps below:
1.Execute git submodule update --init to get the files of thirdparty submodules (google test).
2.Create directory called build in rapidjson source directory.
3.Change to build directory and run cmake .. command to configure your build. Windows users can do the same with cmake-gui application.
4.On Windows, build the solution found in the build directory. On Linux, run make from the build directory.
On successfull build you will find compiled test and example binaries in bin directory. The generated documentation will be available in doc/html directory of the build tree. To run tests after finished build please run make test or ctest from your build tree. You can get detailed output using ctest -V command.
It is possible to install library system-wide by running make install command from the build tree with administrative privileges. This will install all files according to system preferences. Once RapidJSON is installed, it is possible to use it from other CMake projects by adding find_package(RapidJSON) line to your CMakeLists.txt.
It is header-only library. So if you just want to integrate it into your project, just copy the /include folder to your project, and it should works.
All other instructions are for building unit tests, performance tests and documentation.
I am trying to create Rust bindings for the C++ library cryptominisat. The actual code works, but I'm not sure how to properly package it up with Cargo.
The git repository looks like
src/
c++ code here
.gitignore
readme, etc.
I added a rust directory, and created my Cargo project inside of it like so
rust/
cryptominisat/
Cargo.toml
build.rs
src/
rust code here
src/
c++ code here
.gitignore
readme, etc.
Unfortunately, cargo package doesn't seem to want to package up anything outside of the rust/cryptominisat directory, which means it doesn't include the C++ code needed to actually build the library. What can I do? I don't want to move the entire repository into the rust directory if I can avoid it, since that would make it impossible to merge upstream.
The way it's generally solved:
Use a git submodule (or a script run before publishing) to embed a copy of the C++ repo inside the Rust repo (e.g. in rust/cryptominisat/vendor/). During development you could use a symlink instead to avoid having two copies of the C++ code.
Use build.rs to download a tarball/clone/rsync the code at build time. You can dump it into OUT_DIR env var specified by Cargo to avoid polluting user-visible directories.
Make the C++ code a system-level library. The Rust package would not build it, but expect it's already installed, and only search for it and specify link flags for it. That's how most *-sys crates work.