I'd like to execute GMOCK and GTEST tests inside OpenWRT.
I have x86_64 machine. My package is for x32 device.
I tried copy headers manually, but, of course, it does not work.
It is important to run tests inside the device, this is the main reason.
Is it false that the only possible way for me is to compile inside the device?(Such approach is strongly not desired)
If not, how to add gtest&gmock to the package?
You can make a custom package for gtest. Then use that as a dependency for your package. For the headers you will need to setup an InstallDev section in the gtest openwrt package makefile. Use this section to copy the header files to the staging directory where they can be used by your package for compilation.
Follow the documentation for openwrt here:
https://openwrt.org/docs/guide-developer/packages#use_packed_source_code_archive
Related
I am trying to integrate the Refinitiv Real-Time SDK into my own application.
I have downloaded the source code and built the libraries.
Typically you would then expect there to be an INSTALL target, which would install the libraries and headers into some location, and then, if we're lucky, a find_package module which we can later use to import the library targets into our own project.
Unfortunately, neither of these are provided.
How then, to import the libraries and their header files into my project?
ExternalProject_Add
I do not want to use the standard ExternalProject_Add to download and build the source code every time I reconfigure my project. (In particular because our CI server will have to do this for every single build.) Rather I want to build it once (and make it part of the CI server's docker image), and then link against the libraries / include the header files directly from where I've copied the source.
add_library INTERFACE
I know that I can create a new INTERFACE library target
find_library(LIB_EMA ema ${REFINITIV_BINARY_DIR})
find_library(LIB_ETA eta ${REFINITIV_BINARY_DIR})
# etc.. for all the refinitiv libraries
add_library(refinitiv INTERFACE)
target_link_libraries(refinitiv INTERFACE
${LIB_EMA}
${LIB_ETA}
# etc...
)
target_include_directories(refinitiv INTERFACE
${REFINITIV_SOURCE_DIR/Ema/Include
${REFINITIV_SOURCE_DIR/Eta/Include
# etc...
)
This is, however, tedious and prone to breaking whenever Refinitiv releases a new SDK version and decides to change a path or link dependency etc
Question:
What I would to do is use their CMakeLists.txt file, but only to access the already-built targets, not to build them as part of my build.
Is this possible?
I have an existing codebase where a number of third-party dependencies were added as Git submodules, and their directories are directly referenced inside CMakeLists.txt, as in include_directories(../external/foo).
Some of the dependencies are large projects, like FFmpeg, and I'd rather just use the version I installed to my system with a package manager. But the maintainer of the codebase wants to be able to continue using the in-tree dependencies.
I thought a compromise would be to configure CMake to permit both, either using an installed package, or using the in-tree submodules. I think find_package can be used to find the installed package, but is there a good way to implement this behavior that isn't too hacky?
You can add an option to your cmake file that allows the user to switch between the internal FFMpeg or the system one. option(INTREE_FFMPEG "Use the intree ffmpeg" ON). The option can be set either via the cmake-gui or as a command line switch.
I need to work on a codebase that uses another build system, in this case Fastbuild.
I would like to work on it using CLion, which means I need a CMakeLists.txt. It easy enough to import all the files I want to work on.
How can I set it up to call an external script when I want to build an executable?
I'm creating a library (called fmi2) which I intend to install on my local machine (via a package manager) and then link to with a bunch of other libraries.
I'll be providing a Findfmi2.cmake file so that I can call find_package(fmi2) from my other libraries, but where should this file be conventionally installed?
Here are some choices I've considered and their problems:
/usr/share/cmake-3.8/Modules/Findfmi2.cmake
Advantage: find_package(fmi2) will just work
Disadvantage: Only works for one version of cmake
/usr/share/cmake/Modules/Findfmi2.cmake
Advantage: Should work for any version of cmake
Disadvantage: This is not a default folder. We would need to add set(CMAKE_MODULES_PATH /usr/share/cmake/Modules) and this kills any portability.
${CMAKE_CURRENT_SOURCE_DIR}/cmake/Findfmi2.cmake
Advantage: Portable, just need to add set(CMAKE_MODULES_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)
Disadvantage: Not system-wide. Need to manually add this file to each library that uses it. This duplicates files in my framework.
You are authoring content in CMake. You don't need a FindModule. That is designed to find external non-CMake outputs.
This Stackoverflow post from ruslo should help you understand the difference between find_package() module mode and config mode. It also answers your question about paths for FindModules, i.e. they are copied into your CMake project, not discovered system-wide, unless they are part of the official FindModules bundled with CMake in the "Modules" directory.
Modern CMake documentation now finally contains good examples to create a config mode package: cmake-packages
If you want explicit full examples, though using slightly older syntax for the config.cmake files, ruslo has more on Github.
When building the project from command line using mvn clean install everything builds without any issues.
When running some tests that use precompiled C libraries from IntelliJ, tests fail with java.lang.UnsatisfiedLinkError
I may be completely off here, but does IntelliJ not see the .so file? Is so, how can it be added please?
Shared library fails to load with UnsatisfiedLinkError if:
it's not in the working directory configured in the test run configuration.
it's not in PATH environment (on Mac Terminal and GUI apps have different environment, see this answer). Run IDEA from the Terminal open -a /Applications/IntelliJ\ IDEA\ 12.app/ to make environment the same.
it's not in the location specified using -Djava.library.path VM option.
.so depends on some other library that is not found for any of the 1-3 reasons (or the dependency of that dependency is not found, etc).