[
https://issues.apache.org/jira/browse/MESOS-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-6794:
------------------------------------
Component/s: cmake
> 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, cmake
> Reporter: Benjamin Bannier
> Labels: mesosphere, tech-debt
>
> 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)
