[cmake-developers] Automatically set policies for shipped modules

[Rolf Eike Beer]

I have seen multiple commits basically wrapping Modules/* in
cmake_policy(PUSH|POP). I neither find that appealing nor do I think
that this will scale for maintenance.

I suggest that every module included from the CMake installation is
considered clean for whatever we do and automatically gets a policy
scope push/pop right from the C++ level. The policies are all set to
new. This has several advantages:

-we can just use whatever things CMake offers in them
-adding new policies during development would more likely cause things
to "break" earlier, i.e. if a module is not clean for a new policy we
may notice this earlier
-processing of the modules themselves should be slightly faster as the
whole compat code paths are not taken into account right from the start

If a module needs to offer e.g. a function with a specific "old"
behavior it can still explicitely set this policy to whatever value it
needs. It does not need to push/pop as that will be done by the C++ code
anyway.

Opinions?

Eike
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

[Brad King]

Post by Rolf Eike Beer
I suggest that every module included from the CMake installation is
considered clean for whatever we do and automatically gets a policy
scope push/pop right from the C++ level.

That's fine with me for policies like CMP0057 that affect the
CMake language features. We can't do that for every policy
because some policies affect the way modules behave for the
calling project.

When include() or find_package() establishes the policy scope
for the included module we can inject a few settings.

Thanks,
-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

[Craig Scott]

Post by Brad King

Post by Rolf Eike Beer
I suggest that every module included from the CMake installation is
considered clean for whatever we do and automatically gets a policy
scope push/pop right from the C++ level.

That's fine with me for policies like CMP0057 that affect the
CMake language features. We can't do that for every policy
because some policies affect the way modules behave for the
calling project.
When include() or find_package() establishes the policy scope
for the included module we can inject a few settings.

We may also need to be careful about CMP0011 (Included scripts do automatic
cmake_policy PUSH and POP), since that has come up before with regard to
why some modules needed explicit policy push-pop even though include()
would normally do that for us automatically.

[Brad King]

Post by Craig Scott
We may also need to be careful about CMP0011

The policy scope added for our own modules can be marked as a "weak"
scope. This means that specific policies can be set when the scope
is first opened in C++ code, but policy settings inside the scope will
leak out to the parent scope. This inner "weak" scope can be added
to apply CMP0057 and such whether or not the main inclusion has its
own strong scope.

-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers