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

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

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)