Re: [CMake] VS2010 problem with upper case CPP extension
On 04/25/2010 12:10 PM, Michael Wild wrote: On 25. Apr, 2010, at 11:37 , Jarl Lindrud wrote: Hi, I've just run cmake 2.8.1, with the Visual Studio 10 generator, on a cmake project that I've previously been running the VS2008 generator on. There appears to be a problem with C++ source files that end with upper case CPP. They end up in the Visual Studio C++ project, but when I look at the properties of the file, I see Does not participate in build, and indeed, when building, the compiler ignores the file completely. The lower case .cpp files are fine. This issue is easy to reproduce, just use this CMakeLists.txt file: PROJECT(Bug) ADD_EXECUTABLE(Bug File1.cpp File2.CPP) , and create two empty files File1.cpp and File2.CPP (note the case...) FYI: Doesn't work on *nix, too. Did you try to output the values of the following variables? CMAKE_CXX_SOURCE_FILE_EXTENSIONS CMAKE_CXX_IGNORE_EXTENSIONS Won't work: See bugtracker issues 8851, 2360 and additionally http://www.cmake.org/pipermail/cmake/2005-September/007220.html Advice: SET_SOURCE_FILES_PROPERTIES(File2.CPP PROPERTIES LANGUAGE CXX) or go with lower case... ;) Regards, Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Apply FIND_PACKAGE_HANDLE_STANDARD_ARGS() on COMPONENTS
On 04/22/2010 02:04 PM, Michael Wild wrote: On 22. Apr, 2010, at 13:50 , S Roderick wrote: On Apr 22, 2010, at 06:21 , Michael Hertling wrote: On 04/21/2010 09:29 PM, S Roderick wrote: On Apr 21, 2010, at 15:13 , Alexander Neundorf wrote: On Tuesday 20 April 2010, Michael Hertling wrote: Dear CMake community, dear CMake developers, ... There's another aspect related to this I'd like to comment on: During the abovementioned considerations on the bug tracker and the mailing list, the question has arisen if it's reasonable to set XXX_FOUND to FALSE if any of the requested components aren't found. As for myself, I'd say: No, it isn't. Let's have a look at the following scenario: Package XXX normally provides components YY1 and YY2, but for some reason, only YY1 is installed. Moreover, XXX provides a config file XXXConfig.cmake. Now, a project's CMake script requests both YY1/2 by FIND_PACKAGE(XXX COMPONENTS YY1 YY2). As Brad King has pointed out in http://www.mail-archive.com/cmake@cmake.org/msg15952.html, finding a config file results in XXX_FOUND to be set to TRUE automatically. Thus, the absence of YY2 does not mean the absence of XXX as a whole in any case, and, notwithstanding, the requesting CMake script should have a chance to proceed even if YY2 isn't available, i.e. the following seems reasonable: XXX_YY1_FOUND=TRUE, XXX_YY2_FOUND=FALSE *but* XXX_FOUND=TRUE. I think I don't agree here. If I say find_package(XXX COMPONENTS YY1 YY2 REQUIRED) I think it makes a lot of sense to interpret this as search package XXX, and I need YY1 and YY2 from it. What other reason would I have to give YY1 and YY2 there otherwise ? If it still succeeds if they are not found, why should I list them then ? +1 find_package(XXX COMPONENTS YY1 YY2 REQUIRED) means to me, I _require_ both YY1 and YY2 from XXX. Any other YYx I don't care about. Yes, of course, the REQUIRED option is definitive; it's COMPONENTS without REQUIRED which raises the questions. The first version above translates to me to be find_package(XXX COMPONENTS YY1 REQUIRED) I only _require_ YY1. As I have replied recently to AN, I sometimes dislike FIND_PACKAGE() to look for unrequested components, so I need to request them even if they are optional, but this is just my personal preference and, also, not my concern here. My concern is that FIND_PACKAGE(XXX COMPONENTS YY) will always return XXX_FOUND=TRUE if it's driven by XXXConfig.cmake, regardless if YY is found or not, while the same command could return XXX_FOUND=FALSE if driven by FindXXX.cmake since the latter has XXX_FOUND in its hands. Thus, IMHO, it should be reconsidered how XXX_FOUND is interpreted w.r.t. components because I would expect both variants - XXXConfig and FindXXX - to behave the same. That seems to make sense. YY isn't listed as required, therefore it is optional. Having XXX_FOUND=TRUE seems reasonable if CMake found some portion of XXX, regardless of whether it did, or did not, find YY. If we required YY, then we should have added REQUIRED. Now the fact that COMPONENTS and REQUIRED are mutually exclusive is not right IMHO. I'd love to hear Kitware's take on why it was done this way. Stephen I haven't tried it out, but as I read the synopsis of find_package, they are not mutually exclusive. Rather, COMPONENTS is implied if any components are listed after REQUIRED: Yes, this applies better, I think. Possibly, COMPONENTS arises from a syntactical need: You can't say, e.g., FIND_PACKAGE(Qt4 QtCore QtXml), but you must have a keyword to introduce the list of components; else, FIND_PACKAGE() gets confused. Thus, if you don't want to say REQUIRED you have to say something different. # optionally finds component YY of package XX find_package(XXX COMPONENTS YY) # requires that component YY of package XX is found find_package(XXX REQUIRED YY) As far as I've observed, you can use options like QUIET or REQUIRED to mark the end of the components' list; indeed, the following syntax is widely-used: FIND_PACKAGE(Qt4 COMPONENTS QtCore QtGui QtXml REQUIRED), although this can hardly be seen from FIND_PACKAGES()'s specification, IMHO, and hopefully, no one will ever have a package with a component named QUIET, REQUIRED or NO_POLICY_SCOPE... ;) Best regards, Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Apply FIND_PACKAGE_HANDLE_STANDARD_ARGS() on COMPONENTS
On 04/22/2010 01:50 PM, S Roderick wrote: On Apr 22, 2010, at 06:21 , Michael Hertling wrote: On 04/21/2010 09:29 PM, S Roderick wrote: On Apr 21, 2010, at 15:13 , Alexander Neundorf wrote: On Tuesday 20 April 2010, Michael Hertling wrote: Dear CMake community, dear CMake developers, ... There's another aspect related to this I'd like to comment on: During the abovementioned considerations on the bug tracker and the mailing list, the question has arisen if it's reasonable to set XXX_FOUND to FALSE if any of the requested components aren't found. As for myself, I'd say: No, it isn't. Let's have a look at the following scenario: Package XXX normally provides components YY1 and YY2, but for some reason, only YY1 is installed. Moreover, XXX provides a config file XXXConfig.cmake. Now, a project's CMake script requests both YY1/2 by FIND_PACKAGE(XXX COMPONENTS YY1 YY2). As Brad King has pointed out in http://www.mail-archive.com/cmake@cmake.org/msg15952.html, finding a config file results in XXX_FOUND to be set to TRUE automatically. Thus, the absence of YY2 does not mean the absence of XXX as a whole in any case, and, notwithstanding, the requesting CMake script should have a chance to proceed even if YY2 isn't available, i.e. the following seems reasonable: XXX_YY1_FOUND=TRUE, XXX_YY2_FOUND=FALSE *but* XXX_FOUND=TRUE. I think I don't agree here. If I say find_package(XXX COMPONENTS YY1 YY2 REQUIRED) I think it makes a lot of sense to interpret this as search package XXX, and I need YY1 and YY2 from it. What other reason would I have to give YY1 and YY2 there otherwise ? If it still succeeds if they are not found, why should I list them then ? +1 find_package(XXX COMPONENTS YY1 YY2 REQUIRED) means to me, I _require_ both YY1 and YY2 from XXX. Any other YYx I don't care about. Yes, of course, the REQUIRED option is definitive; it's COMPONENTS without REQUIRED which raises the questions. The first version above translates to me to be find_package(XXX COMPONENTS YY1 REQUIRED) I only _require_ YY1. As I have replied recently to AN, I sometimes dislike FIND_PACKAGE() to look for unrequested components, so I need to request them even if they are optional, but this is just my personal preference and, also, not my concern here. My concern is that FIND_PACKAGE(XXX COMPONENTS YY) will always return XXX_FOUND=TRUE if it's driven by XXXConfig.cmake, regardless if YY is found or not, while the same command could return XXX_FOUND=FALSE if driven by FindXXX.cmake since the latter has XXX_FOUND in its hands. Thus, IMHO, it should be reconsidered how XXX_FOUND is interpreted w.r.t. components because I would expect both variants - XXXConfig and FindXXX - to behave the same. That seems to make sense. YY isn't listed as required, therefore it is optional. [...] Sometimes, this decision between required and optional isn't that easy. Imagine some of a package's components are required and some are optional. How would you do the FIND_PACKAGE()? 1) Call it with REQUIRED? This means a missing optional component is capable to terminate the whole configuration process: Bad. 2) Call it without REQUIRED? This means you must handle the absence of a required component by yourself, as well as you have to handle the presence of an optional component: My personal favourite - flexible, clean and quite safe. 3) Call it with REQUIRED and mention the required components only? This means to rely on the find module to search the unmentioned optional components without being requested to do so. Is this guaranteed or, at least, recommended behaviour? E.g., FindQt4 behaves differently: If you want SQL or the like you have to say it. 4) Call it twice, with and without REQUIRED and with a different set of components each time? Which impact would this have on the affected variables in the current scope, the cache, efficiency etc.? For method 2 to be bullet-proof, it's necessary that XXX_FOUND isn't set to false just because any requested components aren't detected. If this would be the case you even simply could not request optional components with FIND_PACKAGE() in a secure manner: XXX_FOUND=FALSE possibly means that XXX actually hasn't been found at all; therefore, you may not rely on any XXX_YY_FOUND having a defined value. Consequently, the right way to check for YY is IF(XXX_FOUND AND XXX_YY_FOUND)...ENDIF(), and this wouldn't work if XXX_YY_FOUND=TRUE while XXX_FOUND=FALSE due to some other XXX_ZZ_FOUND=FALSE. [...] Having XXX_FOUND=TRUE seems reasonable if CMake found some portion of XXX, regardless of whether it did, or did not, find YY. [...] Yes, that's exactly the way I think XXX_FOUND should be interpreted. [...] If we required YY, then we should have added REQUIRED. Even this is no guarantee that you can get rid of explicitly checking a component's availability: FIND_PACKAGE(Qt4 REQUIRED QtCore QtGui QtXml) survives
Re: [CMake] Apply FIND_PACKAGE_HANDLE_STANDARD_ARGS() on COMPONENTS
On 04/21/2010 09:13 PM, Alexander Neundorf wrote:
On Tuesday 20 April 2010, Michael Hertling wrote:
Dear CMake community, dear CMake developers,
...
There's another aspect related to this I'd like to comment on: During
the abovementioned considerations on the bug tracker and the mailing
list, the question has arisen if it's reasonable to set XXX_FOUND to
FALSE if any of the requested components aren't found. As for myself,
I'd say: No, it isn't. Let's have a look at the following scenario:
Package XXX normally provides components YY1 and YY2, but for some
reason, only YY1 is installed. Moreover, XXX provides a config file
XXXConfig.cmake. Now, a project's CMake script requests both YY1/2 by
FIND_PACKAGE(XXX COMPONENTS YY1 YY2). As Brad King has pointed out in
http://www.mail-archive.com/cmake@cmake.org/msg15952.html, finding a
config file results in XXX_FOUND to be set to TRUE automatically. Thus,
the absence of YY2 does not mean the absence of XXX as a whole in any
case, and, notwithstanding, the requesting CMake script should have a
chance to proceed even if YY2 isn't available, i.e. the following seems
reasonable: XXX_YY1_FOUND=TRUE, XXX_YY2_FOUND=FALSE *but* XXX_FOUND=TRUE.
I think I don't agree here.
If I say
find_package(XXX COMPONENTS YY1 YY2 REQUIRED)
I think it makes a lot of sense to interpret this as search package XXX, and
I need YY1 and YY2 from it.
OK, the presence of the REQUIRED option makes everything clear: A find
module or a config file bails out if anything is missing - no worry
about the final value of XXX_FOUND. The actual questions arise if
REQUIRED is absent.
What other reason would I have to give YY1 and YY2 there otherwise ?
Perhaps, because YY2 is optional and I do not want FIND_PACKAGE() to
look for unrequested components, but that's merely my personal habit.
If it still succeeds if they are not found, why should I list them then ?
It is possible for FIND_PACKAGE() - w/o REQUIRED - to succeed although
listed components aren't found, and *this* is what I'm worrying about.
As Brad King has pointed out in the abovementioned post, FIND_PACKAGE()
in config mode sets XXX_FOUND to TRUE if the config file is found and
processed without errors, and there's nothing one can do against it -
unless explicitly terminating the config file which would not be
expected if REQUIRED is absent. Thus, revisiting your question: It's
possible for it to succeed although they are not found, and this is,
IMHO, not a result of a faultily implemented config file and also the
reason why I recommended against setting XXX_FOUND to FALSE in a find
module if not all requested components are present; XXX_FOUND should,
perhaps, be interpreted in a different manner.
Core question reworded: Is it acceptable to obtain a different setting
from FIND_PACKAGE() depending on loading a find module or a config file?
I think by default (no COMPONENTS specified) all components should be
searched. [...]
Or none. Just spontaneously:
- Searching a component could possibly be quite expensive.
- Populating XXX_{DEFINITIONS,LIBRARIES,INCLUDE_DIRS} with all settings
to use the whole thing? E.g., FindQt4 behaves different: Just Core+GUI.
- Again, Brad King from above: Perhaps the project finding Foo just
wants to load some documentation files from it [...], i.e. no
interest in components at all, but only in Foo_ROOT_DIR, e.g.
But, in my opinion, these questions should be a module designer's affair.
[...] By listing components you can say I am ok if at least these are
found. [...]
Or Look for these, and ignore any others., but -- module designer.
[...] (the man page doesn't say anything about how the COMPONENTS should
be interpreted).
Regrettably, that's right. For me, the sole reference
A package-specific list of components may be listed after the REQUIRED
option or after the COMPONENTS option *if no REQUIRED option is given*.
sounds a little bit like COMPONENTS and REQUIRED are intended to be
mutually exclusive, and, indeed, FIND_PACKAGE(... REQUIRED ...) and
FIND_PACKAGE(... COMPONENTS ... REQUIRED) seem not to provide a sole
difference for the find module, only FIND_PACKAGE(... COMPONENTS ...)
without REQUIRED does. Furthermore, one can read in Modules/readme.txt:
The set of components listed after *either* the REQUIRED option or the
COMPONENTS option will be specified in a XXX_FIND_COMPONENTS variable.
Perhaps, we can get some clarifications w.r.t. the particular intention
of the COMPONENTS option, especially when REQUIRED isn't mentioned, too.
Finally, an example: I have endangered my Qt installation by saying
# mv libQtXml.so{,.bak} for testing the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(QT_COMPONENT_TEST)
FIND_PACKAGE(Qt4 COMPONENTS QtCore QtGui QtXml REQUIRED)
MESSAGE(QT4_FOUND: ${QT4_FOUND})
MESSAGE(QT_QTCORE_FOUND: ${QT_QTCORE_FOUND})
MESSAGE(QT_QTGUI_FOUND: ${QT_QTGUI_FOUND})
MESSAGE(QT_QTXML_FOUND: ${QT_QTXML_FOUND
Re: [CMake] Apply FIND_PACKAGE_HANDLE_STANDARD_ARGS() on COMPONENTS
On 04/21/2010 09:29 PM, S Roderick wrote: On Apr 21, 2010, at 15:13 , Alexander Neundorf wrote: On Tuesday 20 April 2010, Michael Hertling wrote: Dear CMake community, dear CMake developers, ... There's another aspect related to this I'd like to comment on: During the abovementioned considerations on the bug tracker and the mailing list, the question has arisen if it's reasonable to set XXX_FOUND to FALSE if any of the requested components aren't found. As for myself, I'd say: No, it isn't. Let's have a look at the following scenario: Package XXX normally provides components YY1 and YY2, but for some reason, only YY1 is installed. Moreover, XXX provides a config file XXXConfig.cmake. Now, a project's CMake script requests both YY1/2 by FIND_PACKAGE(XXX COMPONENTS YY1 YY2). As Brad King has pointed out in http://www.mail-archive.com/cmake@cmake.org/msg15952.html, finding a config file results in XXX_FOUND to be set to TRUE automatically. Thus, the absence of YY2 does not mean the absence of XXX as a whole in any case, and, notwithstanding, the requesting CMake script should have a chance to proceed even if YY2 isn't available, i.e. the following seems reasonable: XXX_YY1_FOUND=TRUE, XXX_YY2_FOUND=FALSE *but* XXX_FOUND=TRUE. I think I don't agree here. If I say find_package(XXX COMPONENTS YY1 YY2 REQUIRED) I think it makes a lot of sense to interpret this as search package XXX, and I need YY1 and YY2 from it. What other reason would I have to give YY1 and YY2 there otherwise ? If it still succeeds if they are not found, why should I list them then ? +1 find_package(XXX COMPONENTS YY1 YY2 REQUIRED) means to me, I _require_ both YY1 and YY2 from XXX. Any other YYx I don't care about. Yes, of course, the REQUIRED option is definitive; it's COMPONENTS without REQUIRED which raises the questions. The first version above translates to me to be find_package(XXX COMPONENTS YY1 REQUIRED) I only _require_ YY1. As I have replied recently to AN, I sometimes dislike FIND_PACKAGE() to look for unrequested components, so I need to request them even if they are optional, but this is just my personal preference and, also, not my concern here. My concern is that FIND_PACKAGE(XXX COMPONENTS YY) will always return XXX_FOUND=TRUE if it's driven by XXXConfig.cmake, regardless if YY is found or not, while the same command could return XXX_FOUND=FALSE if driven by FindXXX.cmake since the latter has XXX_FOUND in its hands. Thus, IMHO, it should be reconsidered how XXX_FOUND is interpreted w.r.t. components because I would expect both variants - XXXConfig and FindXXX - to behave the same. Best regards, Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] I'm confused with Find*.cmake and *-config.cmake
On 04/20/2010 09:40 PM, Benoit Thomas wrote:
On 2010-04-20 03:27, Michael Hertling wrote:
On 04/19/2010 10:07 PM, Benoit Thomas wrote:
I'm using an external library which is already compiled. I have wrapped
the library in a MyLib.cmake and use it in cmake as an imported library.
It works fine, but since the include line uses relative path, it changes
from projects to projects and in some case it looks just wrong.
Just for my understanding: What exactly do you mean with wrapped the
library in a MyLib.cmake and use it in cmake as an imported library?
I'm migrating Visual Studio project to CMake. The Visual Studio projects
use heavy configurations (20+). So, when I used a library which hasn't
yet been converted to cmake, I usually only create a small
CMakeLists.txt for it which look like this:
add_library (MyLib IMPORTED)
set_target_properties (MyLib PROPERTIES IMPORTED_LOCATION_CONFIG1
${MYLIB_ROOT_DIR}/bin/config1/MyLib.lib)
set_target_properties (MyLib PROPERTIES IMPORTED_LOCATION_CONFIG2
${MYLIB_ROOT_DIR}/bin/config2/MyLib.lib)
...
set_target_properties (MyLib PROPERTIES IMPORTED_LOCATION_CONFIG20
${MYLIB_ROOT_DIR}/bin/config20/MyLib.lib)
Then, in another project I'm doing (something like):
include (../../../somewhere/MyLib/CMakeLists.txt)
add_executable (MyExe)
target_link_libraries (MyExe MyLib)
But this line didn't feel right:
include (../../../somewhere/MyLib/CMakeLists.txt)
I renamed the CMakeLists.txt to MyLib.cmake as it's not really a project
file on his own. Also, the path is never the same for all projects so
that's why I wanted to change the format to a find_package (it's
cleaner, and doesn't change if projects are moved).
Oh, I see: Using the IMPORT option of ADD_LIBRARY(). That's the point I
didn't catch; the term wrapped the library in... slightly confused me.
I want to change this to something more like:
find_package (MyLib)
include (MYLIB_CMAKE_FILE)
# add_executable and stuff
target_link_libraries (MyExe MyLib)
This is a possible approach which is also followed by FindQt4.cmake,
but, for several reasons, you shouldn't explicitly refer to MyLib
in TARGET_LINK_LIBRARIES(); use variables from FIND_PACKAGE(MyLib).
I though about using variables, but target_link_libraries doesn't
support configurations, and the other alternative I found was using
LINK_FLAGS. However, using imported library and target_link_libraries
gave me a clean solution.
For me, that's absolutely reasonable. As fas as I understand, the
flexible link time configuration is one of the primary motives for
deploying imported targets instead of the, say, classic method of
referring directly to path/to/library. For the use of variables in
TARGET_LINK_LIBRARIES() when it comes to import libraries, see below.
In the book, there is an example which seems to do more what I want and
use *-config.cmake, which give something like
find_package (MyLib)
# no include, since the MyLib-config.cmake already took care of the include
# add_executable and stuff
target_link_libraries (MyExe MyLib)
What is meant with took care of the include? I don't have the book. ;)
When I look at FindXXX.cmake, they create variables and macros, but they
don't add any targets to your project (I assume this was standard). In
the book, there's an example about creating XXX-config.cmake files. From
my understanding, the XXX-config.cmake include a XXX-targets.cmake which
create the imported target.
I suppose XXX-targets.cmake is a file created by INSTALL(EXPORT ...)
and, thus, contains IMPORTED definitions for all targets declared as
EXPORT in INSTALL(TARGETS ...). This file is thought to be included
by other project's CMakeLists.txt files in order to make the targets
available as imported, but here, one has the same question as you had
initially: Where does this target file resides? Though I can't cite
an example, it's reasonable for me that find modules and config files
include the target file; a find module searches it and a config file
knows it because, usually, they were installed together by the same
CMakeLists.txt. Provided that, a foreign CMakeLists.txt could invoke
FIND_PACKAGE(XXX) for indirect inclusion of the target file, making
XXX's libraries, executables etc. finally available as IMPORTED
targets. Perhaps, it's this you're interested in? However, see:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_Targets
So I was a little confuse about the fact that if I write code like
find_package (MyLib)
# If MyLib is a FindMyLib.cmake, the following code should like
if (MyLib_FOUND)
include (MyLib_USE_FILE) # which would do the add_library (MyLib
IMPORTED)
else()
# print some fatal error message...
endif()
# But if MyLib is a MyLib-config.cmake, there's nothing else to do;
find_package will display an error message if MyLib isn't found, and if
it's found, MyLib-config.cmake will include MyLib
Re: [CMake] I'm confused with Find*.cmake and *-config.cmake
-config.cmake, i.e. a config file, XXX_FOUND is
set to TRUE automatically as finding the config file indicates the
presence of the corresponding package.
My advice: Write a MyLibConfig.cmake file which sets variables like
MyLib_DEFINITIONS, MyLib_INCLUDE_DIRS, MyLib_LIBRARIES etc. to values
needed to use MyLib from another project. Install MyLibConfig.cmake to
${CMAKE_INSTALL_PREFIX}/share/MyLib or the like. Then, from the other
project's CMakeLists.txt files:
FIND_PACKAGE(MyLib)
ADD_DEFINITIONS(${MyLib_DEFINITIONS})
INCLUDE_DIRECTORIES(${MyLib_INCLUDE_DIRS})
# Add your target here.
TARGET_LINK_LIBRARIES(YourTarget ${MyLib_LIBRARIES})
If MyLib is installed in a proper place, see above, you even don't have
to tell CMake where to find it; otherwise, consider CMAKE_PREFIX_PATH
from the command line or via ccmake et al.
'hope this helps a little bit, and to CMake experts: Feel free to beat
me if I'm telling nonsense, but give some enlightenment afterward. ;-)
Best regards,
Michael Hertling
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Apply FIND_PACKAGE_HANDLE_STANDARD_ARGS() on COMPONENTS
or by find module. It is even possible - albeit quite strange - for a package not to provide one single component, but to provide a config file. Consequently, XXX_FOUND should be FALSE if nothing from XXX can be found at all, but if true it should mean: There is something from XXX present, but for information about the available components, imperatively refer to the XXX_YY_FOUND variables. Or, in other words: XXX_FOUND simply does not carry enough information about available components from a multi-component package, so, IMHO, a component's absence isn't sufficient to negate XXX_FOUND. Any comments, suggestions etc. would be greatly appreciated. Best regards, Michael Hertling ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
