On 08/04/2015 04:19 AM, David Faure wrote: > IMHO your logic is inconsistent with the fact that > set(CMAKE_CXX_VISIBILITY_PRESET hidden) > and > set(CMAKE_VISIBILITY_INLINES_HIDDEN 1) > > are ** GLOBAL OPTIONS **, they are not limited to the project.
They are not global options. They have directory scope. The authors of your dependents know you're setting some things for them when they include you, and can optionally isolate these effects by including you in a subdirectory. These dependents willingly ask you to set some things for them by including your central settings module. The compatibility model for policies is that the authors of a project should be aware of changes to CMake's preferred behavior before their project is affected by it. They indicate so by updating their own source to set the policy to NEW. If your dependents want to defer this decision to you and accept the risk of the broken compatibility model then they can include you with NO_POLICY_SCOPE. That is our model. > But maybe this particular behavior change shouldn't be done with > a policy then, but with another global variable. Policies are for when an old behavior is deemed incorrect (as was the lack of visibility settings for all target types). Over time projects will have cmake_minimum_required(VERSION) high enough to set the policy to NEW automatically, and then no one ever notices that the old behavior ever existed. This allows us to fix wrong behavior with no long term cost. A solution that requires a project to write set(DO_IT_RIGHT_THIS_TIME 1) to enable correct behavior forces all future projects to carry that extra setting around forever, and anyone writing a new project to know they need to set this every time. Policies provide a compatible transition path to getting correct behavior without extra per-case code in the long run. -Brad _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
