On 11/18/2010 04:29 AM, Marcel Loose wrote: > I've been following this discussion with interest for quite a while. I > was wondering if both worlds could be united (Alex's and David's) if it > were possible to set cmake_minimum_required on the command line? That > way Alex can be happy, because he doesn't have to modify CMakeLists.txt > files - something he cannot do for previous KDE releaeses; and David > will be happy, because old projects will not suddenly break due to some > incompatible changes in CMake.
Even if it could be set from the command line then the first call to cmake_minimum_required will change it back. We can't just make all calls ignore their argument and use the value from the command line because there can be many calls to in different subdirectories and modules. The entire point of a call to cmake_minimum_required is to say "I was written with this version of CMake in mind". > BTW: IMHO this new policy should default to NEW for CMake 2.8.4 and > later, but I think that's what David suggested as well. See here for the purpose of policies: http://www.cmake.org/Wiki/CMake_Policies Policies absolutely *MUST* default to WARN, no "if-s, and-s, or but-s" about it. If that does not work for this case then a policy is not the solution. This entire issue is about projects using CMAKE_MODULE_PATH to override standard CMake modules (accidentally or intentionally). This "policy" changes the *granularity* at which that has to happen. Previously a project could just copy out *one* module and modify it to fix something. Now it would need to copy out all modules that depend on that module too. This is typically done to fix a bug or gain a feature without waiting for a new CMake release. Ideally the project should have a separate entry in CMAKE_MODULE_PATH for each version of CMake, and then only add those corresponding to versions of CMake newer than or equal to that running. IOW the outside project takes responsibility for the management of module "override" versions. Part of the design of policies is that the NEW behavior is clearly superior to the OLD behavior in design and function. IMO, the NEW behavior of the proposed policy does not have this clear distinction. It makes the typical use case harder to do. This discussion should instead refocus on a way to make it easier for projects to deal with the above copy-and-fix-for-this-version use case. The approach should make it easy for CMake to know whether or not to honor a certain project module directory based on its version. -Brad _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
