[jira] [Issue Comment Deleted] (MESOS-6794) Properly model header dependencies of cmake build components

["Gavin (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MESOS-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gavin updated MESOS-6794:
-------------------------
    Comment: was deleted

(was: www.rtat.net)

> 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: cmake
>            Reporter: Benjamin Bannier
>            Assignee: Andrew Schwartzmeyer
>            Priority: Major
>              Labels: mesosphere, tech-debt
>             Fix For: 1.5.0
>
>
> 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
(v7.6.3#76005)