While I am learning rust, I have a crude means of building a non-rust c/c++ library that lives in a submodule. My build script (build.rs) now looks like:
use std::process::Command;
fn main() {
// EXTERN_C
// Build the c-library
Command::new("make").args(&["-C", "cadd"]).status().unwrap();
// The name of the library to link to, i.e. like: -l<lib>
println!("cargo:rustc-link-lib=dylib=add_x64Linuxd");
// The library search path for linking, i.e. like -L<path>
println!("cargo:rustc-link-search=native=cadd/lib");
// The run-time library search path (LD_LIBRARY_PATH)
println!("cargo:rustc-env=LD_LIBRARY_PATH=cadd/lib");
}
This is working nicely, the makefile within cadd/ sorts out any build/re-build deps etc. The only thing I can't do at the moment is hook in make -C cadd clean when I run cargo clean. Ideally I would like it to run the clean make target at the same time. The command would look like:
Command::new("make").args(&["-C", "cadd", "clean"]).status().unwrap();
But I don't know how to get such a command to run during cargo clean. Is there a "clean script" like there is a "build script" - or another method?
Eventually I will get around to learning how to wrap up my makefile project into a cargo crate (I think that's the right terminology) - so I know this is not the optimal way to do this, but I want to get this working in a basic way first (so my head does not explode!).
The cargo clean command simply deletes the cargo target directory.
One solution is for your Makefile to output its compilation artifacts(all files it generates) into the target directory.
You could also change the directory cargo outputs its artifacts to, either via the --target-dir CLI option or by adding the following to the .cargo/config:
[build]
target-dir = "some/path"
Related
I'm trying to use add_custom_command to generate a file during the build. The command never seemed to be run, so I made this test file.
cmake_minimum_required( VERSION 2.6 )
add_custom_command(
OUTPUT hello.txt
COMMAND touch hello.txt
DEPENDS hello.txt
)
I tried running:
cmake .
make
And hello.txt was not generated. What have I done wrong?
The add_custom_target(run ALL ... solution will work for simple cases when you only have one target you're building, but breaks down when you have multiple top level targets, e.g. app and tests.
I ran into this same problem when I was trying to package up some test data files into an object file so my unit tests wouldn't depend on anything external. I solved it using add_custom_command and some additional dependency magic with set_property.
add_custom_command(
OUTPUT testData.cpp
COMMAND reswrap
ARGS testData.src > testData.cpp
DEPENDS testData.src
)
set_property(SOURCE unit-tests.cpp APPEND PROPERTY OBJECT_DEPENDS testData.cpp)
add_executable(app main.cpp)
add_executable(tests unit-tests.cpp)
So now testData.cpp will generated before unit-tests.cpp is compiled, and any time testData.src changes. If the command you're calling is really slow you get the added bonus that when you build just the app target you won't have to wait around for that command (which only the tests executable needs) to finish.
It's not shown above, but careful application of ${PROJECT_BINARY_DIR}, ${PROJECT_SOURCE_DIR} and include_directories() will keep your source tree clean of generated files.
Add the following:
add_custom_target(run ALL
DEPENDS hello.txt)
If you're familiar with makefiles, this means:
all: run
run: hello.txt
The problem with two existing answers is that they either make the dependency global (add_custom_target(name ALL ...)), or they assign it to a specific, single file (set_property(...)) which gets obnoxious if you have many files that need it as a dependency. Instead what we want is a target that we can make a dependency of another target.
The way to do this is to use add_custom_command to define the rule, and then add_custom_target to define a new target based on that rule. Then you can add that target as a dependency of another target via add_dependencies.
# this defines the build rule for some_file
add_custom_command(
OUTPUT some_file
COMMAND ...
)
# create a target that includes some_file, this gives us a name that we can use later
add_custom_target(
some_target
DEPENDS some_file
)
# then let's suppose we're creating a library
add_library(some_library some_other_file.c)
# we can add the target as a dependency, and it will affect only this library
add_dependencies(some_library some_target)
The advantages of this approach:
some_target is not a dependency for ALL, which means you only build it when it's required by a specific target. (Whereas add_custom_target(name ALL ...) would build it unconditionally for all targets.)
Because some_target is a dependency for the library as a whole, it will get built before all of the files in that library. That means that if there are many files in the library, we don't have to do set_property on every single one of them.
If we add DEPENDS to add_custom_command then it will only get rebuilt when its inputs change. (Compare this to the approach that uses add_custom_target(name ALL ...) where the command gets run on every build regardless of whether it needs to or not.)
For more information on why things work this way, see this blog post: https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
This question is pretty old, but even if I follow the suggested recommendations, it does not work for me (at least not every time).
I am using Android Studio and I need to call cMake to build C++ library. It works fine until I add the code to run my custom script (in fact, at the moment I try to run 'touch', as in the example above).
First of,
add_custom_command
does not work at all.
I tried
execute_process (
COMMAND touch hello.txt
)
it works, but not every time!
I tried to clean the project, remove the created file(s) manually, same thing.
Tried cMake versions:
3.10.2
3.18.1
3.22.1
when they work, they produce different results, depending on cMake version, one file or several. This is not that important as long as they work, but that's the issue.
Can somebody shed light on this mystery?
On Linux, if I build my project with cargo build, the result will be placed in target/debug. If I instead build it with cargo build --target x86_64-unknown-linux-gnu, the result is put in target/x86_64-unknown-linux-gnu/debug, even though the result is the same.
It's inconvenient to supply the --target argument when I run commands manually. Setting build.target in .cargo/config.toml isn't very convenient either as I'd have to make sure to always do that. Our build scripts on the other hand need an explicit --target, because those scripts may run on different systems. For example, we want to make Windows builds on a Linux machine or vice versa.
If I mix manual commands (where I don't want to manually type out --target) and scripts (that use --target to make sure they build for the correct platform), Cargo will spend a lot of time rebuilding the same thing in two different directories.
So, that's why I wonder if it is possible to configure Cargo so that it puts the result in target/<target>/<mode> even when there is no explicit --target argument.
I need to build libpng, but without #define PNG_READ_eXIf_SUPPORTED in pnglibconf.h
I've read comments from pnglibconf.dfa, and here are some ways of disabling features, however I didn't manage to make what I want using them.
The problem is in that, build process is performed on build server, so I can't change any files inside of libpng submodule. Here is how server works:
Download clone sources from git
Generate makefile by running cmake ..
Run make command.
Thus I have libnpg, but with included PNG_READ_eXIf_SUPPORTED option.
Libpng is a submodule of my project, so it checked out by build server automatically so I can't change pnglibconf manually.
As it said in pnglibconf.dfa file:
There are three ways of disabling features, in no particular order:
1) Create 'pngusr.h', enter the required private build information
detailed below and #define PNG_NO_<option> for each option you
don't want in that file in that file. You can also turn on options
using PNG_<option>_SUPPORTED. When you have finished rerun
configure and rebuild pnglibconf.h file with -DPNG_USER_CONFIG:
make clean
CPPFLAGS='-DPNG_USER_CONFIG' ./configure
make pnglibconf.h
pngusr.h is only used during the creation of pnglibconf.h, but it
is safer to ensure that -DPNG_USER_CONFIG is specified throughout
the build by changing the CPPFLAGS passed to the initial ./configure
I tried to do what is written here. I run cmake .. -DCMAKE_C_FLAGS="-DPNG_USER_CONFIG -I/home/me/dev/include" where /home/me/dev/include - is a path to pngusr.h file
Then I run make command. However, PNG_READ_eXIf_SUPPORTED is still present in generated (by make command pnglibconf.h file).
So my main question is how to make libpng without PNG_READ_eXIf_SUPPORTED option?
It remains unclear to me whether and to what extent the specific customization mechanism you are trying to use works in the version of libpng you are trying to use. But it looks like there's a simpler way. Just below the excerpt you posted, in the same file, is the second (of three) alternatives:
2) Add definitions of the settings you want to change to CPPFLAGS;
for example:
-DPNG_DEFAULT_READ_MACROS=0
(lightly formatted). I'm not in a good position to test that on the CMake-based build system, but it seems to work like a charm in the Autotools build system. From examining and comparing the two, I think it will work for CMake, too. In particular, you would want to run
cmake .. -DCMAKE_CPP_FLAGS="-DPNG_NO_READ_eXIf"
for your particular case.
Note, by the way, that the CPP (i.e. preprocessor) flags are the right place for an option such as you are specifying (for -DPNG_USR_CONFIG in your original attempt, too). In practice, though, they probably still work in the C compiler flags.
I want to run the following commands side by side
cargo watch "check"
cargo watch "build"
I want to run cargo watch build in the background and use cargo watch check to look at the error messages.
The problem is that cargo watch check always runs after cargo watch build and then also needs to wait on the file lock
cargo check
Blocking waiting for file lock on build directory
I don't think that a file lock would be required for cargo check. Is it possible to disable file locking in cargo?
I don't think that a file lock would be required for cargo check.
I can think of in one reason: build scripts. A build script can generate files that are included in the crate, checking the crate without generating the files would probably produce errors. Running 2 instances of a build script in parallel is not a good idea (conflicting file writes, etc), so the locking is required.
I want to run the following commands side by side
You have two options:
Sequential: install cargo-do and run
cargo watch "do check, build"
this will first run cargo check and then cargo build (if cargo check did not find an error).
Parallel: change the target-dir for one of the two cargo commands:
CARGO_TARGET_DIR=/tmp cargo watch check
I can't seem to find much about this, so maybe it isn't possible... or I am searching with the wrong keywords.
Anyway, I have a directory of source. Let's say that there is a folder within Source called Tests and another called Products. I have the usual hierarchy of CMakeLists.txt files so that I can build all the source in each directory and subdirectory, etc... What I want to know is if it is possible to pass a command line argument with cmake so that it will only build the tests folder or the source folder.
e.g. something like cmake TEST ..
Thanks
Of course you can use flags.
if(TEST)
include needed folders
else()
do something else
endif()
And call cmake like this:
cmake -DTEST=1 ..
You can create them as different targets. CMake will configure all of them, but then you can run make test or make product. An example would be:
project(myProject)
add_subdirectory(tests)
add_subdirectory(products)
add_executable(test EXCLUDE_FROM_ALL ${TEST_SRC_FILES})
add_executable(product EXCLUDE_FROM_ALL ${PRODUCT_SRC_FILES})
In each subdirectory you would have a CMakeLists.txt that builds the source file variables. The EXCLUDE_FROM_ALL means that just typing make won't build either tests or products, but you can decide if you want that to happen or not.
To build, you can do make test or make product and it will build only that target (and any dependencies).