[CMake] C header file cross dependency
Wagner Martin
Martin.Wagner at neuberger.net
Thu Jun 23 04:19:49 EDT 2016
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
More information about the CMake
mailing list