[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