On Monday 22 November 2010, Brad King wrote: > On 11/20/2010 11:30 AM, Alexander Neundorf wrote: > > CMake Warning (dev) > > at /opt/cmake-HEAD/share/cmake-2.9/Modules/CheckCXXCompilerFlag.cmake:23 > > (INCLUDE): > > File /opt/cmake-HEAD/share/cmake-2.9/Modules/CheckCXXCompilerFlag.cmake > > includes > > /home/alex/src/kde4-svn/KDE_dir/kdelibs/cmake/modules/CheckCXXSourceCompi > >les.cmake (found via CMAKE_MODULE_PATH) which shadows > > /opt/cmake-HEAD/share/cmake-2.9/Modules/CheckCXXSourceCompiles.cmake. > > This may cause errors later on . > > Good. The warning should be more specific about what "cause errors later > on" means. It could mean both "with future versions of CMake" and "with > this version of CMake later on during *this* configuration". The latter is > more important.
I think this is hard to know. I can know that it works right now with some given version of cmake. E.g. KDE requires CMake 2.6.4. I knew that everything worked fine with 2.6.4 to 2.8.2. If 2.8.4 would detect that shadowing, it still wouldn't know whether this shadowing would actually cause any breakage due to incompatiblity later (e.g. directly after that file has been processed) on. At cmake-time the current cmake may be the "future cmake release" from code-writing-time. I don't see a way how to figure out whether the current cmake is a cmake which may be hit by such an issue. > > The policy set to NEW would indeed break the build for such projects > > which rely on their own compiler info files. > > That's okay because once the project source has been edited to set the > policy to NEW then it is their responsibility to make other corresponding > fixes. ... > The only problem is how to get users building KDE that see an obscure > FPHSA argument error over to instructions to add this cmd line option. > Perhaps your proposed "shadow" warning for CMP0017 that appears just > before the breakage will help. Yes, I can add something more there. > I think the path forward here is: > > (1) Improve documentation of CMAKE_USER_MAKE_RULES_OVERRIDE[_C] variables > (2) Add the Custom-<*> file inclusion, document it Do you think both (1) and (2) are necessary ? > (3) Teach cmake_policy(VERSION) to honor CMAKE_POLICY_DEFAULT_* > (4) Introduce the proposed policy CMP0017 Sounds good I think. Alex _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
