Internal propagation of usage requirements

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Internal propagation of usage requirements

Lukas Böger

Dear cmake-Gurus,

When unit tests and an exported library shall be compiled with identical _private_ settings (include directories, compiler flags etc.), I see these options:

(1) define variables to be passed to target_* functions for both library and test target
    + simple solution
    - violates avoid-variables-idiom
    - possibly uses "non-local" variables defined in another CMakeLists.txt (reduces readability)

(2) link both library and test targets against an internal, usage-requirement-only interface library
    + modern approach, no variables, only target_* functions invoked
    - when compiling a static library, the internal target must be exported, too (though "filtered" by LINK_ONLY later on)

(3) retrieve lib properties via get_property, then propagate them via target_* functions
    + variables in use have a "local" scope of the CMakeLists.txt
    - verbose and clumsy

Am I missing a solution? Which one is preferable and why? Any pro/cons that I haven't seen?

Thanks for any advice!

Best,
Lukas


--

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:
https://cmake.org/mailman/listinfo/cmake