[CMake] gnu-arm-embedded toolchain and CMAKE_FORCE_C_COMPILER
Hi @all, In recent CMake versions I get a deprecated message for using the cmake_force_xxx_compiler() function inside my toolchain file. After searching, I found that there are two threads on the CMake list, one https://cmake.org/pipermail/cmake/2016-February/062773.html just ending without a solution and referencing to https://cmake.org/pipermail/cmake-developers/2016-February/027888.html which also doesn’t really tell me how this is supposed to work in my case. From those threads, I was able to modify my toolchain file: - replaced force_compiler function with regular set(CMAKE... - added line set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) as linking needs a linker script. However, it fails with the following output: exit.c:(.text.exit+0x1a): undefined reference to `_exit' collect2: error: ld returned 1 exit status which to me indicates that CMake ignores the STATIC_LIBRARY flag and tries linking. Has anyone successfully modified their toolchain file to correctly detect the gnu-arm-embedded toolchain? Thanks for your help! Regards, Martin Terminal output: ~~ -- The C compiler identification is GNU 6.2.1 -- The CXX compiler identification is GNU 6.2.1 -- Check for working C compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc CMake Error at /home/user/workspace/project/buildsupport/toolchains/toolchain_stm32f303xB_freertos.cmake:37 (include): include could not find load file: /home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeTmp/buildsupport/toolchains/toolchain_arm-cortex-m4f.cmake Call Stack (most recent call first): /home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CMakeSystem.cmake:6 (include) /home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeTmp/CMakeLists.txt:2 (project) CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc -- broken CMake Error at /usr/share/cmake-3.7/Modules/CMakeTestCCompiler.cmake:51 (message): The C compiler "/opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc" is not able to compile a simple test program. It fails with the following output: -- Configuring incomplete, errors occurred! See also "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeOutput.log". See also "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeError.log". CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:17 (project) ~~ CMakeOutput.log The target system is: Generic - - arm-freertos-eabi The host system is: Linux - 4.9.0-1-amd64 - x86_64 Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: -c The output was: 0 Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.o" The C compiler identification is GNU, found in "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdC/CMakeCCompilerId.o" Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-g++ Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: -c The output was: 0 Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.o" The CXX compiler identification is GNU, found in "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdCXX/CMakeCXXCompilerId.o" Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: -c The output was: 0 Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.o" The C compiler identification is GNU, found in "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdC/CMakeCCompilerId.o" Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-g++ Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: -
[CMake] import external library
Hi @all,
I’ve tried importing an external library like that:
stackoverflow.com/questions/31274577
I have the same use case, except that my custom target does not call make but
does unpack a tar archive containing headers and .a.
My problem is that the step
“
# specify where the library is and where to find the headers
set_target_properties(lib2
PROPERTIES
IMPORTED_LOCATION ${LIB_FILE}
INTERFACE_INCLUDE_DIRECTORIES ${LIB_HEADER_FOLDER})
“
fails. When running cmake, I get an error that the header dir specified with
“INTERFACE_INCLUDE_DIRECTORIES” does not exist.
“
CMake Error in src/CMakeLists.txt:
Imported target "whatever" includes non-existent path
"/path/to/include"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not
provide.
“
This is true, as the header path is only generated when running the unpack
target. Is there a way to tell cmake to skip this check?
Thanks!
Regards,
Martin
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] install() rename with version string -solved-
Thank you very much! This did the trick
>
> Well, the second install command has the wrong scope:
> install(CODE "include(version.cmake)")
> install(FILES firmware.hex
> RENAME firmware_\${version_string}.hex
> DESTINATION firmware)
>
I've tried that before, but without the
firmware_>\<-${version_string}.hex escape.
Looking at the generated cmake_install.cmake makes obvious why it needs to be
escaped.
if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL
"Unspecified")
include(${CMAKE_BINARY_DIR}/version.cmake)
endif()
if(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL
"Unspecified")
file(INSTALL DESTINATION "firmware.hex" TYPE FILE RENAME
"firmware_${version_string}.hex" FILES "path.../firmware.hex ")
endif()
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] install() rename with version string
Thanks for your answers.
> >You will need to do the install as another target/command. For
> >example:
> >
> >add_custom_command( TARGET version
> > POST_BUILD
> > COMMAND ${CMAKE_COMMAND} -D
> >VERSION=${version_string}
> > -P install_commands.cmake
> > USES_TERMINAL )
>
> Or even simpler, do all of that in the install_commands.cmake by using
> install(CODE) AND escaping the $.
> Just looking at the generated install_commands.cmake will make this much
> clearer.
>
I think I don't properly understand what you mean. Can you please give me an
example?
I've tried
install(CODE "
Include(version.cmake)
install(FILES firmware.hex RENAME firmware_\${version_string}.hex
DESTINATION firmware)
")
This is correctly expanded in generated "cmake_install.cmake" script, runs
without errors, but does not install the file.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] install() rename with version string
That doesn't work as CMake seems to only evaluate the include() statement once
at first run. With the OPTIONAL statement, my project builds, but the
${version_string} variable is not populated.
Von: Eric Noulard [mailto:eric.noul...@gmail.com]
Gesendet: Donnerstag, 19. Januar 2017 13:00
An: Wagner Martin
Cc: cmake@cmake.org
Betreff: Re: [CMake] install() rename with version string
You can try:
include(version.cmake OPTIONAL)
which will make include tolerate the absence of version.cmake,
but then your install statement will only be OK after version.cmake has been
created.
2017-01-19 9:30 GMT+01:00 Wagner Martin :
Hello,
I’ve searched for some time, but didn’t find anything useful. Most finds deal
with including version system stuff passed to header files for compilation.
I want to achieve something like that:
Include(version.cmake)
install(FILES firmware.hex RENAME firmware_${version_string}.hex)
where version.cmake is created like explained in this mail
https://cmake.org/pipermail/cmake/2010-July/038015.html alongside headers
needed for compilation.
However, CMake needs to include version.cmake at first CMake run time, which is
not possible because it’s a generated file.
Is there any other way to do the rename?
Thanks for your help!
Regards,
Martin
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Eric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] install() rename with version string
Hello,
I’ve searched for some time, but didn’t find anything useful. Most finds deal
with including version system stuff passed to header files for compilation.
I want to achieve something like that:
Include(version.cmake)
install(FILES firmware.hex RENAME firmware_${version_string}.hex)
where version.cmake is created like explained in this mail
https://cmake.org/pipermail/cmake/2010-July/038015.html alongside headers
needed for compilation.
However, CMake needs to include version.cmake at first CMake run time, which is
not possible because it’s a generated file.
Is there any other way to do the rename?
Thanks for your help!
Regards,
Martin
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] C header file cross dependency
Hi @all, I've finally found a solution to the problem. My solution is here: https://github.com/martinwag/test_cmake/tree/master What I did: - remove "OBJECT" library targets as they do not work in combination with interface libraries - added one install target per library, so I get one "lib*.a" archive per library (which is not what I need) - added an post install target as described here: stackoverflow.com/questions/9998679 . This step creates a "thin" archive, that is packed with the other archives at cpack-time. This archive can be used as single file when linking in the consuming stage. Regards, Martin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] C header file cross dependency
Hi Patrick,
thank you for your answer and sorry that it took me a while to work on it.
>
> I forked your repo and played a little bit around.
>
> https://github.com/pboettch/test_cmake
I pulled those changes and played aroud a bit myself.
https://github.com/martinwag/test_cmake
I'm now back at the point where I decided to use cmake's OBJECTS functionality.
I didn't find any other way to pack all compiled products into an
easy-to-include-and-link package for the application.
I was unable to use target_link_libraries() because this actually wants to do
linking instead of just packaging. The way you used it
add_library(bsp INTERFACE)
target_link_libraries(bsp INTERFACE drivers terminal)
install(TARGETS bsp DESTINATION ${ARCHIVE_INSTALL_DIR})
the install command runs, but does not install anything, resulting in an
archive with just the headers.
I'm open to package the archive in a different way - install(EXPORT ...) seems
promising. The important thing to me is that the consuming application doesn't
need inside knowledge of the bsp package.
>
> Here are my conclusions:
>
> 1) Due to the use of add_libary(... OBJECTS ...) you cannot link
> libraries with libraries or interfaces, this is a pity - especially for
> a complex project with a lot of sub-dirs.
>
> There is a possibility to merge STATIC-libraries to generated one big
> archive using external tools (libtool). If I were you I'd try to this
> way to profit from the target_*-cmake-features.
See above.
>
> 2) I created a log-dir with an interface-library - which only carries
> the log.h and thus the printf-prototypes
>
> 3) Both, drivers and terminal link with this interface-library (to get
> their hands on log.h)
>
This sounds good - I have to check if that works in the (more complex)
production code.
> 4) In addition I added two libraries to drivers/ uart-logging1 and uart-
> logging2. This shows how you could compile-configure your printf-
> function depending on the hardware used. In the main CMakeLists you just
> need to select one of them - depending on the option's value.
>
> Basically I followed the idea of instantiating a print-function
> 'somewhere' in the project (it could also be done outside) and then
> select the one you want to use at the final link.
>
> Of course this way you could add other ways of printf'ing - logging1 and
> logging2 are just stupid examples.
This is -more or less- already in my production code. I want to do all this
stuff in one configuration header file inside the application.
However, I think it's a good idea to have the option to replace the printing
function with "anything".
I removed that part to keep the example as simple as possible.
>
> HTH and sorry for the delay,
Obviously I'm not the fastest myself :-).
Regards,
Martin
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] C header file cross dependency
> > Could you provide a working, stripped down example to show the problem > provided via github (in an example repo). > I've added a simple test project to https://github.com/martinwag/test_cmake/tree/master Note that this example does not need cross gcc for ARM. It doesn't implement any useful functionality! Regards, Martin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] C header file cross dependency
Thank you for your answer!
> > How do I resolve something like this? Right now CMake evaluates the
> > compiler includes in the order that subdirectories are added. This
> > gives me an compilation error in uart.c that terminal.h cannot be
> > found.
>
> This is not a cmake-problem, but seems to be a code-structure-issue.
>
> I'm guessing here: if terminal needs the uart-code shouldn't it be the
> uart-code filling in a terminal-function. Interface vs. implementation?
> Could you elaborate more on how terminal and uart are linked?
The terminal code implements a "printf()" equivalent function to log debug and
state information. All input is then directly written to the UART.
The UART driver now wants to use this terminal logging function. It doesn't
care how printf() works.
In the end, this is necessary because there is no file system to store the log
information to. I would like to have this:
uart_write(uart2) -> syslog(prio, errormsg) -> syslog.txt on file system.
But I have:
uart_write(uart2) -> printf(errormsg) -> uart_write(uart1) -> PC with running
terminal software
>
> Regarding cmake: I suggest you stop using include_directories() and
> start using target_include_directories() and
> target_compile_definitions() instead of add_definitions().
I will have a look at this.
>
> Limiting yourself to this way of doing libraries and targets, cmake will
> force you to structure your code in a more standard way - and will
> provide you with clean visibility between different targets.
>
> Could you provide a working, stripped down example to show the problem
> provided via github (in an example repo).
I will try to do this within a few days...
>
> More comments below.
>
> > Some excerpt of my project. I've tried to keep the example as simple
> > as possible.
> >
> > My directory structure looks something like that:
> > /
> > CMakeLists.txt
> > src +
> > +CMakeLists.txt(1)
> > +drivers+
> > | +uart.c
> > | +uart.h
> > | +...
> > | +CMakeLists.txt(2)
> > +os-+
> > | +terminal.c
> > | +terminal.h
> > | +...
> > | +CMakeLists.txt(3)
> >
> >
> > (1):
> >
> > SET(drivers "drivers")
> > SET(terminal "terminal")
> >
> > SET(drivers_lib ${drivers})
> > SET(terminal_lib ${terminal})
> >
> > SET(ARCHIVE_INSTALL_DIR lib)
> > SET(INCLUDE_INSTALL_DIR include)
> >
> > SET(headers_private "_headers_private") # internal headers
> > SET(headers_public "_headers_public") # public headers go into
> > package
> >
> > ADD_SUBDIRECTORY(${drivers})
> > ADD_SUBDIRECTORY(${terminal})
>
> I think it is common practice now to use lower-case for cmake-commands
> now.
OK.
>
> > ## drivers
> >
> > ## Sources
> > ---
> > SET(sources "uart.c"
> > )
> >
> > ## Header includes
> > ---
> > SET(headers "${CMAKE_CURRENT_SOURCE_DIR}/"
> > )
> > SET(${drivers}${headers_public} ${headers} PARENT_SCOPE)
> >
> > INCLUDE_DIRECTORIES(${headers}
> > ${${terminal}${headers_public}}
> > )
>
> While the ${${var}${var2}} (seems to) work, it is error-prone, IMHO.
>
> Standard cmake-commands can work with relative paths and are evaluating
> them correctly taking into account ${CMAKE_CURRENT_SOURCE_DIR} (most of
> the time. So you could use ../uart in terminal/
This is what I did to continue working...
> - but it would be better
> if it comes indirectly via target_include_directories() and
> target_link_libraries()
...and this is why I asked the list :-)
>
> >[..]
> >
> > And finally this creates the package in root directory CMakeLists.txt:
> >
> > SET(CPACK_PROJECT_CONFIG_FILE ${CMAKE_BINARY_DIR}/CPackOptions.cmake)
> > # CPackOptions.cmake contains package file name SET(CPACK_GENERATOR
> > "TBZ2") INCLUDE(CPack)
>
> Due to the circular header-dependency the binaries of terminal and uart
> should have the same mutual dependency. In this case you could build
> them in within one target.
Yes, I could do that. But I wanted to get away from one single, monolithic
makefile...
This is why I created one CMake file for every functional unit of my source
code (drivers, RTOS, terminal and so on).
regards,
Martin
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] C header file cross dependency
Hi @all,
I'm quite new to CMake. If I've made a mistake or something is much easier to
solve, please tell me.
I'd like to use CMake in embedded development (Build System: Linux, Target: ARM
Microcontroller) to get rid of complicated makefiles.
We're building multiple devices where stuff like embedded rtos and peripheral
drivers are identical, so I'd like to separate this part from the user
application. I've achieved that by creating an object library out of all source
and header files, and packing those files using CPack. This archive is then
statically linked against the user application.
So far this worked fine. However, now I have to use driver functions in the
rtos source code and vice versa, resulting in cross-dependencies for header
files:
#include uart.h
#include terminal.h
function() {}
#include terminal.h
#include uart.h
function() {}
How do I resolve something like this? Right now CMake evaluates the compiler
includes in the order that subdirectories are added. This gives me an
compilation error in uart.c that terminal.h cannot be found.
Thank you for your help!
Regards,
Martin
Some excerpt of my project. I've tried to keep the example as simple as
possible.
My directory structure looks something like that:
/
CMakeLists.txt
src +
+CMakeLists.txt(1)
+drivers+
| +uart.c
| +uart.h
| +...
| +CMakeLists.txt(2)
+os-+
| +terminal.c
| +terminal.h
| +...
| +CMakeLists.txt(3)
(1):
SET(drivers "drivers")
SET(terminal "terminal")
SET(drivers_lib ${drivers})
SET(terminal_lib ${terminal})
SET(ARCHIVE_INSTALL_DIR lib)
SET(INCLUDE_INSTALL_DIR include)
SET(headers_private "_headers_private") # internal headers
SET(headers_public "_headers_public") # public headers go into package
ADD_SUBDIRECTORY(${drivers})
ADD_SUBDIRECTORY(${terminal})
## Targets
---
ADD_LIBRARY(bsp ${object_libs})
INSTALL(TARGETS bsp DESTINATION ${ARCHIVE_INSTALL_DIR})
(2):
## drivers
## Sources
---
SET(sources
"uart.c"
)
## Header includes
---
SET(headers
"${CMAKE_CURRENT_SOURCE_DIR}/"
)
SET(${drivers}${headers_public} ${headers} PARENT_SCOPE)
INCLUDE_DIRECTORIES(${headers}
${${terminal}${headers_public}}
)
## Targets
---
ADD_LIBRARY(${drivers_lib} OBJECT ${sources})
# add to list of Object Targets
SET(object_libs ${object_libs} $ PARENT_SCOPE)
INSTALL(DIRECTORY ${headers} DESTINATION ${INCLUDE_INSTALL_DIR} FILES_MATCHING
PATTERN "*.h")
(3), mostly like (2):
## rtos
## Sources
---
SET(sources
"terminal.c"
)
## Header includes
---
SET(headers
"${CMAKE_CURRENT_SOURCE_DIR}/"
)
SET(${terminal}${headers_public} ${headers} PARENT_SCOPE)
INCLUDE_DIRECTORIES(${headers}
${${drivers}${headers_public}}
)
## Targets
---
ADD_LIBRARY(${terminal_lib} OBJECT ${sources})
# add to list of Object Targets
SET(object_libs ${object_libs} $ PARENT_SCOPE)
INSTALL(DIRECTORY ${headers} DESTINATION ${INCLUDE_INSTALL_DIR} FILES_MATCHING
PATTERN "*.h")
And finally this creates the package in root directory CMakeLists.txt:
SET(CPACK_PROJECT_CONFIG_FILE ${CMAKE_BINARY_DIR}/CPackOptions.cmake) #
CPackOptions.cmake contains package file name
SET(CPACK_GENERATOR "TBZ2")
INCLUDE(CPack)
I've searched for a solution for this problem for ~1 day, most results only
deal with one directional dependencies or link a shared library/executable at
the end, which does not help me.
When changing (2) "INCLUDE_DIRECTORIES" to
INCLUDE_DIRECTORIES(${headers}
"/home/user/workspace/arm_bsp/src/terminal/"
)
compilation works as expected, but breaks independence of child folders to
parent folders. I defenitively do not want to do that.
CMake Version is "cmake version 3.0.2" (stock Debian 8)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
