Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
Description
The cmake build includes multiple components, most notably from our side stout, libprocess, and mesos proper. Headers from libprocess might include stout headers; mesos might include headers from both stout and libprocess.
If any of the subcomponents require external library or in particular header dependencies, these most likely should be announced to users as well, e.g., if a header file stout/numify.hpp has a dependency on Boost, any user of that header file needs Boost as well, and should e.g., update his [target_]include_directories accordingly.
Currently we pass these environment variables up the chain via magic variables like STOUT_INCLUDE_DIRS which get wrapped in PROCESS_INCLUDE_DIRS and ultimately used in mesos magic vars like MASTER_INCLUDE_DIRS. This approach does not use cmake dependency tracking to propagate component-specific flags and is manual, overly verbose, and error prone.
Note for all its deficiencies our current approach is still inferior to e.g., just declaring target_include_directories in a component and then consuming target as a dependency higher up the chain which would not only properly propagate target's header and library dependency settings (correctly taking into account the difference between e.g., SYSTEM, PUBLIC, or PRIVATE header files). It also appears that such an approach would compose better, and be less verbose and error-prone.
We should move to using cmake to track component dependencies instead of our current manual approach wherever possible. More modern cmake versions (i.e., 3.0+) also include support for tracking header dependencies of header-only libraries with the INTERFACE abstraction which would enable us to use the same approach even for stout.
Attachments
Issue Links
- is blocked by
-
MESOS-6350 Raise minimum required cmake version
-
- Resolved
-