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 ----------------------------------------- _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem