[ https://issues.apache.org/jira/browse/MESOS-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188891#comment-16188891 ]
Joseph Wu commented on MESOS-3107: ---------------------------------- {code} commit 3f15dedb221a6882fd01b172f584527c496d4e1e Author: Andrew Schwartzmeyer <and...@schwartzmeyer.com> Date: Mon Oct 2 14:12:30 2017 -0700 CMake: Used `TRUE|FALSE` instead of `ON|OFF` consistently. While these are equivalent values to CMake, we should be consistent. Also made uses of `option` consistent, and moved `ENABLE_JAVA` to the 3rdparty section. Review: https://reviews.apache.org/r/62730/ {code} > Define CMake style guide > ------------------------ > > Key: MESOS-3107 > URL: https://issues.apache.org/jira/browse/MESOS-3107 > Project: Mesos > Issue Type: Task > Components: cmake > Reporter: Alex Clemmer > Assignee: Andrew Schwartzmeyer > Labels: build, cmake > > The short story is that it is important to be principled about how the CMake > build system is maintained, because there CMake language makes it difficult > to statically verify that a configuration is correct. It is not unique in > this regard, but (make is arguably even worse) but it is something that's > important to make sure we get right. > The longer story is, CMake's language is dynamically scoped and often has > somewhat odd defaults for variable values (_e.g._, IIRC, target names passed > to ExternalProject_Add default to "PREFIX" instead of erroring out). This > means that it is rare to get a configuration-time error (_i.e._, CMake > usually doesn't say something like "hey this variable isn't defined"), and in > large projects, this can make it very difficult to know where definitions > come from, or whether it's important that one config routine runs before > another. Dynamic scoping also makes it particularly easy to write spaghetti > code, which is clearly undesirable for something as important as a build > system. > Thus, it is particularly important that we lay down our expectations for how > the CMake system is to be structured. This might include: > * Function naming (_e.g._, making it easy to tell whether a function was > defined by us, and where it was defined; so we might say that we want our > functions to have an underscore to start, and start with the package the come > from, like libprocess, so that we know where to look for the definition.) > * What assertions we want to check variable values against, so that we can > replace subtle errors (_e.g._, a library is accidentally named something > silly like "PREFIX.0.0.1") with an obvious ones (_e.g._, "You have failed to > define your target name, so CMake has defaulted to 'PREFIX'; please check > your configuration routines") > * Decisions of what goes where. (_e.g._, the most complex parts of the CMake > MVPs is in the configuration routines, like `MesosConfigure.cmake`; to curb > this, we should have strict rules about what goes in that file vs other > files, and how we know what is to be run before what. Part of this should > probably be prominent comments explaining the structure of the project, so > that people aren't confused!) > * And so on. -- This message was sent by Atlassian JIRA (v6.4.14#64029)