Hello Brad, 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. If one "dependency" sets this, it affects the whole project. There is clearly a need to fine-tune what these things do. But maybe this particular behavior change shouldn't be done with a policy then, but with another global variable. Random idea: set(CMAKE_CXX_VISIBILITY_ALL_TARGETS_PRESET hidden) i.e. keep CMAKE_CXX_VISIBILITY_PRESET applying to only shared libs, and have another variable for a preset that applis to shared libs, static libs and executables. (this is from what I remember of this issue, maybe there's a better solution for fine-tuning what these global variables do). Basically it sounds to me like cmake is starting to overuse this policy thing, as a bad excuse for changing behavior all the time, when more source-compatible changes could be made instead. David. On Friday 31 July 2015 19:36:07 Alex Merry wrote: > David, > > CMake won't accept the patch we discussed, and Brad says that projects should > either set NO_POLICY_SCOPE when they include the file, or else set the policy > manually themselves. > > Alex > > ---------- Forwarded Message ---------- > > Subject: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New > PARENT_SCOPE > argument > Date: Friday 31 July 2015, 13:30:03 > From: Brad King <brad.k...@kitware.com> > To: Alex Merry <alex.me...@kde.org> > CC: cmake-develop...@cmake.org > > On 07/31/2015 12:54 PM, Alex Merry wrote: > >> Setting policies centrally breaks their compatibility model. > > > > I should perhaps explain our use case: > > My assertion stands regardless of the use case. > > > Now, sure, we could change every single project that includes this module > > to > > use NO_POLICY_SCOPE but, apart from that being an unwanted change in how we > > tell people to use this module, it seems a very clunky approach. > > That is the correct approach. > > If a project wants to opt-in to letting KDECompilerSettings set > policies for it (and therefore accept the risk of the broken > compatibility model) then it should state so explicitly by > including the module with NO_POLICY_SCOPE. > > > It means the module is at risk of leaking policy settings it didn't mean to > > Use cmake_policy(PUSH/POP) around most of the module. Then set > policies explicitly outside of that scope if they are intended > to be set for includers that use NO_POLICY_SCOPE. > > > you are asking users to opt-in to this particular behavoural change > > Yes, because the behavior change comes from a CMake version update. > > The purpose of policies is to not change behavior for a project until > it is modified to be aware of the CMake version that makes the change. > For this compatibility model to work the modification must be made > in the project itself, not in one of its dependencies. > > -Brad > > ----------------------------------------- -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem