I have a C++ project with a core which is basically self-contained but with a lot of interfaces to third party codes that a user may or may not want to compile. We build the code using CMake and I am now trying to organize the code a bit better.
The solution I came up with is to add to the top CMakeLists.txt file a set of options which determine whether a dependent package should be located or not.
option(WITH_FOO "Compile the interface to Foo, if found" ON)
option(REQUIRE_FOO "Require that the Foo interface to be compiled" OFF)
option(WITH_BAR "Compile the interface to Bar, if found" ON)
option(REQUIRE_BAR "Require that the Bar interface to be compiled" OFF)
...
if(WITH_FOO)
if(REQUIRE_FOO)
find_package(Foo REQUIRED)
else(REQUIRE_FOO)
find_package(Foo)
endif(REQUIRE_FOO)
else(WITH_FOO)
set(FOO_FOUND FALSE)
endif(WITH_FOO)
if(WITH_BAR)
if(REQUIRE_BAR)
find_package(Bar REQUIRED)
else(REQUIRE_BAR)
find_package(Bar)
endif(REQUIRE_BAR)
else(WITH_BAR)
set(BAR_FOUND FALSE)
endif(WITH_BAR)
Then in the the CMakeLists.txt files in the subdirectories, there will be statements such as:
if(BAR_FOUND)
add_subdirectory(bar_interface)
endif(BAR_FOUND)
I don't particularly like this solution, partly because it is very verbose and partly because I feel that there should be some more standardized way of doing this. Is anyone aware of a better, more maintainable solution?
Have a look at the following standard CMake modules:
FeatureSummary - Macros for generating a summary of enabled/disabled features
CMakeDependentOption - Macro to provide an option dependent on other options
Examples of using FeatureSummary (from manual):
option(WITH_FOO "Help for foo" ON)
add_feature_info(Foo WITH_FOO "The Foo feature provides very cool stuff.")
find_package(LibXml2)
set_package_properties(LibXml2 PROPERTIES DESCRIPTION "A XML processing library." URL "http://xmlsoft.org/")
set_package_properties(LibXml2 PROPERTIES TYPE RECOMMENDED PURPOSE "Enables HTML-import in MyWordProcessor")
set_package_properties(LibXml2 PROPERTIES TYPE OPTIONAL PURPOSE "Enables odt-export in MyWordProcessor")
feature_summary(WHAT ALL)
Related
i have recently switched my stm32 project to CMake to be independent on IDE. Root repository (application) contains multiple submodules (HAL, FreeRTOS etc.) and its CMakeLists.txt includes explicitly every single used file:
set(EXECUTABLE ${PROJECT_NAME}.elf)
add_executable(${EXECUTABLE}
# Own sources
src/main.c
src/SEGGER_SYSVIEW_Config_FreeRTOS.c
src/startup_stm32h723zgtx.s
src/stm32h7xx_hal_timebase_tim.c
src/system_stm32h7xx.c
# Base CMSIS and HAL library
lib-hal/stm32h7xx/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_tim.c
lib-hal/stm32h7xx/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_tim_ex.c
lib-hal/stm32h7xx/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_uart.c
lib-hal/stm32h7xx/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc.c
lib-hal/stm32h7xx/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc_ex.c
#long list of HAL c files there...
# FreeRTOS library
lib-freertos/croutine.c
lib-freertos/event_groups.c
lib-freertos/list.c
lib-freertos/queue.c
lib-freertos/stream_buffer.c
lib-freertos/tasks.c
lib-freertos/timers.c
lib-freertos/portable/GCC/ARM_CM7/r0p1/port.c
lib-freertos/trace/Sample/FreeRTOSV10/SEGGER_SYSVIEW_FreeRTOS.c
lib-freertos/trace/SEGGER/Syscalls/SEGGER_RTT_Syscalls_GCC.c
lib-freertos/trace/SEGGER/SEGGER_RTT_ASM_ARMv7M.S
lib-freertos/trace/SEGGER/SEGGER_RTT_printf.c
lib-freertos/trace/SEGGER/SEGGER_RTT.c
lib-freertos/trace/SEGGER/SEGGER_SYSVIEW.c
)
target_include_directories(${EXECUTABLE}
PRIVATE
include
src
lib-hal/stm32h7xx/CMSIS/Include
lib-hal/stm32h7xx/CMSIS/Device/ST/STM32H7xx/Include
lib-hal/stm32h7xx/STM32H7xx_HAL_Driver/Inc
lib-freertos/include
lib-freertos/trace/Config
lib-freertos/trace/SEGGER
lib-freertos/trace/Sample/FreeRTOSV10/
lib-freertos/portable/GCC/ARM_CM7/r0p1
)
This solution works but i know it is not a sustainable approach. So i tried to create library in lib-hal and lib-freertos submodules, specifying their sources and includes
add_library(lib-hal-stm32h7xx)
target_include_directories(lib-hal-stm32h7xx
PUBLIC
CMSIS/Include
CMSIS/Device/ST/STM32H7xx/Include
STM32H7xx_HAL_Driver/Inc
PRIVATE
STM32H7xx_HAL_Driver/Src
)
target_sources(lib-hal-stm32h7xx
PRIVATE
STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_tim.c
STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_tim_ex.c
STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_uart.c
STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc.c
STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc_ex.c
#long list of HAL c files there...
)
and then using
add_subdirectory(lib-hal/stm32h7xx)
add_subdirectory(lib-freertos)
and
target_link_library(${EXECUTABLE} lib-freertos lib-hal-stm32h7xx)
to "import" submodules into application project. But when building the executable, gcc cannot access files stm32h7xx_hal_conf.h and FreeRTOSConfig.h which are located in root directory include. I do not want to put configuration headers into submodules because they are used in multiple projects with different configurations. Is it possible to somehow extend already specified directory search scope for library after adding it into parent project?
File structure of project:
-src
-include (configuration for lib-hal and lib-freertos included there)
-lib-hal
-includes...
-sources...
-lib-freertos
-includes...
-sources...
Thanks in advance for response.
As Tsyvarev mentioned in the comments, you can modify the properties of the target in your project. To keep things clean, I usually create a function for this and place it in a separate file.
Tip: you can also add source files to the target. In case of FreeRTOS, you could add architecture-specific files, in case all your projects don't run on the same MCU family.
function(configure_freertos target_name)
target_sources(${target_name}
PRIVATE
lib-freertos/portable/GCC/ARM_CM7/r0p1/port.c
)
target_include_directories(${target_name}
PUBLIC
include
lib-freertos/portable/GCC/ARM_CM7/r0p1
)
endfunction()
Running
val myAvroObject = MyAvroObject.newBuilder()
results in a compilation error:
Cannot access class 'MyAvroObject.Builder'. Check your module classpath for missing or conflicting dependencies
I am able to access other MyAvroObject variables. More precisely, methods such as
val schema = MyAvroObject.getClassSchema()
val decoder = MyAvroObject.getDecoder()
compiles fine. What makes it even stranger is that I can access newBuilder() in my test/ folder, but not in my src/ folder.
Why do I get a compile error when using newBuilder()? Is the namespace of the avro-schema used to generate MyAvroObject of importance?
Check your module classpath generally means, that your dependencies (which you didn't provide) are messed up. One of them should read implementation instead of testImplementation, in order to have the method available in the main source-set, instead of only the test source-set - but this may well have to do with the input classes, the output location of generated classes, or annotations alike #VisibleForTesting (just see what it even generates). Command gradlew can also list the dependencies per configuration. The builder seems to be called org.apache.avro.SchemaBuilder... there's only avro-1.11.0.jar & avro-tools-1.11.0.jar. With the "builder" design pattern, .newBuilder() tries to return inner class Builder.
had the same problem today and was able to solve it by adding the following additional source folder
<sourceDir>${project.basedir}/target/generated-sources/avro</sourceDir>
to the kotlin-maven-plugin.
As the title states, is there a 'neat' way to set per configuration linker flag? It is not possible for me to use target_link_options() since I'm trying to link into a static library. Ideally, what I would want to achieve is to set Visual Studio's Librarian -> Additional Dependencies and Additional Library Directories and achieve the same result in XCode as well.
Here is what I've achieved so far:
set(LIB_LINKS_RUNTIME
${Vulkan_LIBRARIES}
${CMAKE_SOURCE_DIR}/bin/$<CONFIGURATION>/SDL2maind.lib
${CMAKE_SOURCE_DIR}/bin/$<CONFIGURATION>/SDL2d.lib
${CMAKE_SOURCE_DIR}/bin/$<CONFIGURATION>/imgui.lib
)
foreach(lib ${LIB_LINKS_RUNTIME})
set (CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} ${lib}")
endforeach()
According to https://cmake.org/cmake/help/latest/prop_tgt/STATIC_LIBRARY_OPTIONS.html STATIC_LIBRARY_OPTIONS property does the trick
set_property(TARGET Runtime PROPERTY STATIC_LIBRARY_OPTIONS ${LIB_LINKS_RUNTIME})
For a specific project I am moving out of qmake and now have to use cmake.
My path are the following:
Source : ~/Projects/Project
External static library (OSVR in this instance) paths : ~/osvr/lib/ , ~/osvr/include/osvr /osvr/include/jsoncpp
Using qmake, the linking part to that library used to be:
INCLUDEPATH += /usr/include
LIBS += -L$$PWD/../../osvr/lib/ -losvrClientKit -losvrClient -losvrCommon -losvrUtil -ljsoncpp
INCLUDEPATH += $$PWD/../../osvr/include/
INCLUDEPATH += $$PWD/../../jsoncpp/include/
DEPENDPATH += $$PWD/../../osvr/lib/
Now I need to use cmake, but the library is not linked to:
The relevant part of my cmake.txt:
set(OSVR_DIR /home/pilou/osvr)
set(OSVR_INCLUDE_DIR /home/pilou/osvr/include/osvr/ClientKit)
find_library(OSVR_LIBRARIES ${OSVR_DIR}/lib)
[...]
target_link_libraries(myexec ${QT_LIBRARIES} ${OSVR_LIBRARIES} )
target_include_directories(myexec PUBLIC include ${OSVR_DIR}/include )
Which doesn't work...
A little help would be lovely as I am not too sure about how:
to ensure the external include folder is scanned
to link to my 3 libraries osvrClientKit osvrClient osvrCommon.
As a matter of fact I am also interested in a good explanation.
Thanks in advance.
EDIT : Thanks to the reply from ComicSansMs and for the posterity, the working Cmake syntax :
set(OSVR_DIR /home/pilou/osvr)
set(OSVR_INCLUDE_DIR /home/pilou/osvr/include)
find_library(OSVR_CLIENT_KIT_LIBRARY osvrClientKit HINTS ${OSVR_DIR}/lib)
find_library(OSVR_CLIENT_LIBRARY osvrClient HINTS ${OSVR_DIR}/lib)
find_library(OSVR_COMMON_LIBRARY osvrCommon HINTS ${OSVR_DIR}/lib)
find_library(OSVR_UTIL_LIBRARY osvrUtil HINTS ${OSVR_DIR}/lib)
find_library(JSONCPP_LIBRARY jsoncpp HINTS ${OSVR_DIR}/lib/x86_64-linux-gnu)
set(OSVR_LIBRARIES ${OSVR_CLIENT_KIT_LIBRARY} ${OSVR_CLIENT_LIBRARY} ${OSVR_COMMON_LIBRARY} ${OSVR_UTIL_LIBRARY} ${JSONCPP_LIBRARY})
and down the track:
target_link_libraries(myExec ${QT_LIBRARIES} ${OSVR_LIBRARIES} )
target_include_directories(myExec PUBLIC include ${OSVR_INCLUDE_DIR} )
Your use of find_library looks wrong.
Check out the manpage for find_library. You have to give the name of the library you want to find as an argument. You can optionally provide additional hints where to find that library:
find_library(OSVR_COMMON_LIBRARY osvrCommon
HINTS ${OSVR_DIR}/lib)
Note that you will need one separate find_library call for each library! Since your libraries seem to have interdependencies, the correct way to model them in CMake is to also add an imported target per library and then model the interdependencies on those targets correctly.
If you don't feel comfortable doing that yet, you can also add all the find libraries to a single OSVR_LIBRARIES variable in the correct order and then depend on that:
find_package(OSVR_COMMON_LIBRARY ...)
find_package(OSVR_CLIENT_LIBRARY ...)
find_package(OSVR_CLIENTKIT_LIBRARY ...)
...
set(OSVR_LIBRARIES ${OSVR_CLIENTKIT_LIBRARY} ${OSVR_CLIENT_LIBRARY} ${OSVR_COMMON_LIBRARY} ...)
target_link_libraries(myexec ${QT_LIBRARIES} ${OSVR_LIBRARIES})
Note though that this approach is quite fragile with regards to future changes and should in general be avoided in favor of the imported targets.
Also, be sure that you actually have proper error handling mechanisms in place for the case that your find calls do not actually find anything.
I have the same question related to this:
aop.xml name and location?
In the answers, it says:
use the system property:
-D org.aspectj.weaver.loadtime.configuration=META-INF/myaop.xml
What does "use the system property" mean?
create a aop.properties file?
Or, write in the vm option?
AFAIK there is no such thing as aop.properties. Have you just made this up? The hint means you should specify the property as a JVM command line parameter like this, if the given path can be resolved as a Java resource path/URL:
java ... -Dorg.aspectj.weaver.loadtime.configuration=META-INF/myaop.xml ...
If you explicitly want to point to the file system, you have to precede the path by file:, e.g.
java ... -Dorg.aspectj.weaver.loadtime.configuration=file:META-INF/myaop.xml ...
or
java ... -Dorg.aspectj.weaver.loadtime.configuration=file:c:\my\path\META-INF\myaop.xml ...
Attention: no white space between -D and the property name!
Update:
What does "use the system property" mean?
Your favourite search engine will lead you to pages like:
Oracle Java tutorial
System Javadoc, specifically methods
getProperties(),
getProperty(String),
getProperty(String, String),
setProperties(Properties),
setProperty(String, String),
clearProperty()