My toolset:
Windows 10 x64 (1909)
Bazel 3.1.0
Visual Studio 2019 (16.6)
Powershell
I need to use a prebuild third-party C++ DLL. The third-party lib looks like this:
<directory> third-party-lib
├── <directory> bin
| ├── <file> third_party_lib.dll
| └── <file> third_party_libd.dll
├── <directory> lib
| ├── <file> third_party_lib.lib
| └── <file> third_party_libd.lib
└── <directory> includes
└── <file> third_party_lib.h
So there are two versions a release and a debug version. Filenames ending with "d" indicate the debug version.
To consume this library I am using a cc_import target:
cc_import(
name = "third-party-lib",
interface_library = "lib/third_party_lib.lib",
shared_library = "bin/third_party_lib.dll",
)
My build target depends on the third-party-lib. Building in release (opt) mode works without any problems:
bazel build //:MyBuildTarget
But if I try to do a debug build I run into linker problems:
bazel build --compilation_mode=dbg //:MyBuildTarget
Is there any possibility to specify debug and release DLLs in cc_import rule? Or is there any other rule that can I use for this propose?
You can use select() to switch between library variants:
cc_import(
name = "third-party-lib",
interface_library = "lib/third_party_lib.lib",
shared_library = select({
":debug_build": "third_party_libd.dll",
"//conditions:default": "third_party_lib.dll",
}),
)
config_setting(
name = "debug_build",
values = {
"compilation_mode": "dbg",
},
)
Related
I'm trying to build a helloworld package example with a cmake recipe. My problem is bitbake give me an error because it can't find CMakeLists.txt in the /tmp/work/core2-64-poky-linux/helloworld/0.1-r0 folder.
The error :
helloworld-0.1-r0 do_configure: Execution of '/path-to-tmp/tmp/work/core2-64-poky-linux/helloworld/0.1-r0/temp/run.do_configure.28001' failed with exit code 1:
CMake Error: The source directory "/path-to-tmp/tmp/work/core2-64-poky-linux/helloworld/0.1-r0/files" does not appear to contain CMakeLists.txt.
My package is in my layer meta-mylayer/recipes-core/helloworld :
meta-mylayer/
├── conf
│ └── layer.conf
├── COPYING.MIT
├── README
└── recipes-core
└── helloworld
├── files
│ ├── CMakeLists.txt
│ └── main_helloworld.c
└── helloworld_0.1.bb
My CMakeLists.txt :
cmake_minimum_required(VERSION 2.4)
project(helloworld)
file(GLOB_RECURSE files/*.c)
add_executable(app ${src_files})
install(TARGETS helloworld DESTINATION bin)
My helloworld_0.1.bb :
PN="helloworld"
PV="0.1"
P="${PN}-${PV}"
DESCRIPTION="This is my package helloworld"
LICENSE="CLOSED"
FILESEXTRAPATHS_prepend:="${THISDIR}/${PN}:"
RDEPENDS_${PN}+=""
DEPENDS+=""
DEPENDS+="cmake"
SRC_URI+="file://CMakeLists.txt file://main_helloworld.c"
S="${WORKDIR}/files"
inherit pkgconfig cmake
I can't find my files in /path-to-tmp/tmp/work/core2-64-poky-linux/helloworld/0.1-r0/*
Why files are not copied? I'm using yocto Dunfell.
Thanks for your help.
When you have files in SRC_URI they are installed in ${WORKDIR}.
The following recipe will do the trick:
DESCRIPTION="This is my package helloworld"
LICENSE="CLOSED"
SRC_URI+="file://CMakeLists.txt file://main_helloworld.c"
S="${WORKDIR}"
inherit pkgconfig cmake
Also, your CMakeLists.txt should not find files in files directory.
S is set to ${WORKDIR} because this is where the files from the file:// fetcher are put by default.
DEPENDS already has cmake-native in it from the cmake bbclass you inherited. You don't need to depends on cmake, because you depends on cmake-native (you need to execute cmake at build time, you don't need cmake headers or sources).
The FILESEXTRAPATHS that was added is already by default used by bitbake (and it's also not matching your directory layout).
PN and PV are gotten from the filename of the bb recipe, no need to set them again.
I have a few libraries/applications (supplied by a third party vendor, so changing them is not really an option) that are built in a non standard way. Basically, there are libraries that link to other libraries in a weird way.
Here's what I'm talking about:
.
├── libA
│ ├── include
│ │ └── headerA.h
│ └── src
└── libB
├── include
│ └── headerB.h
└── src
libA includes libB headers using the "" syntax, i.e. #include "headerB.h
" and -I compile option is passed to include the libB/include/ directory. However, linking to libA poses a problem, because I need to include libB include directory as well.
That's not a huge problem, because the headers get installed into the targets sysroot. Let's say the libB headers are installed into ${SYSROOT}/usr/include/libB.
Now, for some reason the sysroot directory is passed using the ${CMAKE_C_FLAGS} instead of ${CMAKE_SYSROOT} as it probably should. I tried parsing ${CMAKE_C_FLAGS} to get the sysroot like this:
execute_process(COMMAND "echo \"${CMAKE_C_FLAGS}\""
COMMAND "grep -Eo '\\-\\-sysroot=\\S*'"
COMMAND "sed 's:--sysroot=::g'"
OUTPUT_VARIABLE SYSROOT
RESULT_VARIABLE SYSROOT_RESULT
)
However, this always fails with "No such file or directory". I figured it's failing to one of the commands, i.e. either echo, grep or sed. How do I fix this? Or maybe there's a better way altogether?
I have some tests that I would like to ignore when using cargo test and only run when explicitly passed a feature flag. I know this can be done by using #[ignore] and cargo test -- --ignored, but I'd like to have multiple sets of ignored tests for other reasons.
I have tried this:
#[test]
#[cfg_attr(not(feature = "online_tests"), ignore)]
fn get_github_sample() {}
This is ignored when I run cargo test as desired, but I can't get it to run.
I have tried multiple ways of running Cargo but the tests continue to be ignored:
cargo test --features "online_tests"
cargo test --all-features
I then added the feature definition into my Cargo.toml as per this page, but they continue to be ignored.
I am using workspaces in Cargo. I tried adding the feature definition in both Cargo.toml files with no difference.
Without a workspace
Cargo.toml
[package]
name = "feature-tests"
version = "0.1.0"
authors = ["An Devloper <an.devloper#example.com>"]
[features]
network = []
filesystem = []
[dependencies]
src/lib.rs
#[test]
#[cfg_attr(not(feature = "network"), ignore)]
fn network() {
panic!("Touched the network");
}
#[test]
#[cfg_attr(not(feature = "filesystem"), ignore)]
fn filesystem() {
panic!("Touched the filesystem");
}
Output
$ cargo test
running 2 tests
test filesystem ... ignored
test network ... ignored
$ cargo test --features network
running 2 tests
test filesystem ... ignored
test network ... FAILED
$ cargo test --features filesystem
running 2 tests
test network ... ignored
test filesystem ... FAILED
(some output removed to better show effects)
With a workspace
Layout
.
├── Cargo.toml
├── feature-tests
│ ├── Cargo.toml
│ ├── src
│ │ └── lib.rs
├── src
│ └── lib.rs
feature-tests contains the files from the first section above.
Cargo.toml
[package]
name = "workspace"
version = "0.1.0"
authors = ["An Devloper <an.devloper#example.com>"]
[features]
filesystem = ["feature-tests/filesystem"]
network = ["feature-tests/network"]
[workspace]
[dependencies]
feature-tests = { path = "feature-tests" }
Output
$ cargo test --all
running 2 tests
test filesystem ... ignored
test network ... ignored
$ cargo test --all --features=network
running 2 tests
test filesystem ... ignored
test network ... FAILED
(some output removed to better show effects)
With a virtual workspace
Virtual workspaces do not support specifying features (Cargo issue #4942). You will need to run the tests from within the sub project or specify the path to the appropriate Cargo.toml
Layout
.
├── Cargo.toml
└── feature-tests
├── Cargo.toml
└── src
└── lib.rs
feature-tests contains the files from the first section above.
Cargo.toml
[workspace]
members = ["feature-tests"]
Output
$ cargo test --all --manifest-path feature-tests/Cargo.toml --features=network
running 2 tests
test filesystem ... ignored
test network ... FAILED
$ cargo test --all --manifest-path feature-tests/Cargo.toml
running 2 tests
test filesystem ... ignored
test network ... ignored
(some output removed to better show effects)
For my NSIS uninstaller, I want to check if a process is running. FindProcDLL is not working under Windows 7 x64, so I tried nsProcess.
I've downloaded the version 1.6 from the website: http://nsis.sourceforge.net/NsProcess_plugin
If I start the nsProcessTest.nsi in the Example folder, I get the following errors:
Section: "Find process" ->(FindProcess)
!insertmacro: nsProcess::FindProcess
Invalid command: nsProcess::_FindProcess
Error in macro nsProcess::FindProcess on macroline 1
Error in script "C:\Users\Sebastian\Desktop\nsProcess_1_6\Example\nsProcessTest.nsi" on line 14 -- aborting creation process
This is line 14 of the example script:
${nsProcess::FindProcess} "Calc.exe" $R0
Do somebody know what is wrong? How can I check if a process is running with NSIS?
NSIS does not find the plug-in, so make sure you copied its files to the correct folder.
NSIS 2.x:
NSIS/
├── Include/
│ └── nsProcess.nsh
└── Plugins/
└── nsProcess.dll
NSIS 3.x:
NSIS/
├── Include/
│ └── nsProcess.nsh
└── Plugins/
├── x86-ansi/
│ └── nsProcess.dll
└── x86-unicode/
└── nsProcess.dll
The file inside Plugins\x86-unicode is nsProcessW.dll renamed to nsProcess.dll (blame the author for making it overly complicated!)
More generally, refer to How can I install a plugin? on the NSIS Wiki.
I'm trying to configure CMake and ninja as a build system for my project. Except the app itself I have an extra executable for unit tests powered by gtest. I thought it would be nice to have them executed automatically whenever they are built. Here's how I made it:
├── build
└── source
├── CMakeLists.txt
├── main.cc
└── ut
├── CMakeLists.txt
├── gtest
│ ├── ...
└── ut.cc
source/CMakeLists.txt...
cmake_minimum_required (VERSION 2.6)
project (trial)
add_subdirectory(ut)
add_executable(trial main.cc)
...and source/ut/CMakeLists.txt:
add_subdirectory(gtest)
include_directories ("gtest/include")
add_executable(ut ut.cc)
target_link_libraries(ut LINK_PUBLIC gtest_main)
add_custom_target(run_uts
COMMAND ut
DEPENDS ut
WORKING_DIRECTORY ${CMAKE_PROJECT_DIR}
)
Now when I build it, i.e.:
cd build
cmake -GNinja ../source
ninja run_uts
It works fine except that the output is colorless. When I run the ut binary by hand, i.e. build/ut/ut I get nice green and red colors. The colors are also there when I use Unix Makefiles as a genrator for CMake.
Since I'm only learning CMake, is there something I missed or is it an issue with Ninja?
I assume your automated code runs a gtest executable and directs the output to a file. By default, gtest adds color sequences only when sending output to a terminal. In order to force it to add color sequences to output sent to a file or a pipe, run your test executable with the --gtest_color=yes option.