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