Benjamin Bannier created MESOS-6794:
---------------------------------------
Summary: Properly model header dependencies of cmake build
components
Key: MESOS-6794
URL: https://issues.apache.org/jira/browse/MESOS-6794
Project: Mesos
Issue Type: Bug
Components: build
Reporter: Benjamin Bannier
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
