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

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

    [ https://issues.apache.org/jira/browse/MESOS-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16102058#comment-16102058 ] 

Andrew Schwartzmeyer commented on MESOS-6794:
---------------------------------------------

I have this well in progress. I'm at the point that I've deleted all of `StoutTestsConfigure.cmake` and `StoutConfigure.cmake`. The rest will come. Magic variables will be no more!

> 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
>            Assignee: Andrew Schwartzmeyer
>              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.4.14#64029)