On Thursday 22 April 2010, Michael Hertling wrote: > 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 -
Well, find_package() could be enhanced to set this considering the specified COMPONENTS. There hasn't been much discussion about how the COMPONENTS arguments should be interpreted until now. > 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}>") > > When run from a clean directory - no cache and the like - it yields: > > [...] > QT4_FOUND: <YES> > QT_QTCORE_FOUND: <1> > QT_QTGUI_FOUND: <1> > QT_QTXML_FOUND: <> > [...] Hmm, not for me ( and I also didn't remember such behaviour): ammer:~/src/tests/findqt4/b262$ cat ../CMakeLists.txt cmake_minimum_required(VERSION 2.6) find_package(Qt4 COMPONENTS QtXML) message(STATUS "QT_QTXML_FOUND ${QT_QTXML_FOUND}") message(STATUS "QT_QTXML_LIBRARY ${QT_QTXML_LIBRARY}") hammer:~/src/tests/findqt4/b262$ /opt/cmake-2.6.2-Linux-i386/bin/cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found. -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found. -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found. -- Found Qt-Version 4.6.0 -- Found OpenSSL: /usr/lib/libssl.so -- Looking for _POSIX_TIMERS -- Looking for _POSIX_TIMERS - found -- QT_QTXML_FOUND 1 -- QT_QTXML_LIBRARY /opt/kde-qt/lib/libQtXml.so -- Configuring done -- Generating done -- Build files have been written to: /home/alex/src/tests/findqt4/b262 Alex _______________________________________________ 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