[cmake-developers] User vs CMake include mismatch handling

Brad King brad.king at kitware.com
Wed Dec 15 17:31:57 EST 2010


On 12/15/2010 04:59 PM, Brad King wrote:
> On 12/15/2010 04:35 PM, Alexander Neundorf wrote:
>> First get all information, then look and decide what to do.
>> Seemed the cleanest way to me.
> 
> Searching the filesystem is not cheap.  Do it lazily.
> 
>> I tried to incorporate all other comments, and also tried to add some 
>> documentation about CMAKE_POLICY_DEFAULT_CMP<NNNN>, but I think you can word 
>> it better. I pushed the changes to the branch on stage.
> 
> I'll take a look when I get more time.

The error of CMAKE_POLICY_DEFAULT_CMP<NNNN>=xyz looks better.

This hunk should more reliably detect whether the includer is a builtin
module:

-    const char* currentFile = this->GetDefinition("CMAKE_CURRENT_LIST_FILE");
-    if (currentFile && (strstr(currentFile, cmakeRoot) == currentFile))
+    const char* includer = this->CallStack.empty()?
+      0 : this->CallStack.back().Context->FilePath.c_str();
+    if(includer && cmSystemTools::IsSubDirectory(includer, cmakeRoot))

And this hunk should improve the warning message:

-          e << "File " << currentFile << " includes "
-            << moduleInCMakeModulePath
-            << " (found via CMAKE_MODULE_PATH) which shadows "
-            << moduleInCMakeRoot  << ". This may cause errors later on .\n"
+          e << "CMake builtin module\n"
+            << "  " << includer << "\n"
+            << "is including a module from the CMAKE_MODULE_PATH\n"
+            << "  " << moduleInCMakeModulePath << "\n"
+            << "which shadows expected builtin module\n"
+            << "  " << moduleInCMakeRoot << "\n"
+            << "This may cause CMake or build errors later.\n"

-Brad



More information about the cmake-developers mailing list