[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