[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