[cmake-developers] Missing docs for CMAKE_FIND_PACKAGE_NAME and possible cmake code generation bug.

Brad King brad.king at kitware.com
Mon Oct 1 15:34:32 EDT 2012


On 10/01/2012 03:27 PM, Stephen Kelly wrote:
> In commit 6f50a04cc1c4584472f850e06daad7ae20af45c4, a

For reference here is a link to the commit:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6f50a04c

> CMAKE_FIND_PACKAGE_NAME variable was introduced, but not documented. 
> Sometimes it is deliberate to not document things like that, but I thought 
> I'd ask if it is. 

Alex, please add documentation for this variable next to where
we document the other CMAKE_FIND_* variables.

> The same commit generates cmake code with uppercasing, but with empty endif 
> commands. 

I think all target export file code is still generated upper case.

> I think I saw that cmake code generated by cmake remains uppercase in case 
> anyone using an older cmake is processing files generated by a newer cmake. 
> Does the same apply to populating the end* commands? 

We've supported empty end*() and case-insensitive commands for so long this
shouldn't be a problem in generated code.

Actually use of the variable CMAKE_FIND_PACKAGE_NAME won't work when
a targets file is loaded by older CMake versions, but in this case that
should just lead to a less informative error message.

-Brad



More information about the cmake-developers mailing list