Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)
On 2013-10-19 20:16+0200 Alexander Neundorf wrote: On Thursday 17 October 2013, Stephen Kelly wrote: Brad King wrote: On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. A new, similar --find-target mode or similar may be more appropriate: cmake --find-target --package Qt5Widgets --target Qt5::Widgets ... # KF5Config exports 3 independent targets: cmake --find-target --package KF5Config --target KF5::ConfigCore ... cmake --find-target --package KF5Config --target KF5::ConfigGui ... cmake --find-target --package KF5Config --target KF5::ConfigWidgets ... Yes, that will work. And a new command/option is not even necessary. The name of the target could be given as additional option. If none is given, it will use the variables as it does now, if a target is given, it will use this target and its properties. I'll work on that when I find the time (and nobody is faster). How is that going, Alex? I have just reviewed this thread, and it appears at first you were rather discouraged about continuing with --find-package because of a lot of brokeness, but now you see a way forward. And that is good because being able to access compile or link flags for a given library with a simple command is extremely useful functionality. For example, as I explained in a different thread (see subject line --find-package option fails with some of the Qt5 components on the cmake mailing list), PLplot requires access to the compile and link flags for certain components of Qt5. And it appears (but please correct me if I am wrong) that --find-package is the only way to obtain that information. However, when I tried --find-package, it only partially worked for Qt5. Steve responded to that thread by saying --find-package was your department. :-) Now that I have found this thread, I tried the same experiment with CMake-3.0.0-rc3 with the following good and bad results: wine@raven ~software/cmake/install-3.0.0-rc3/bin/cmake --find-package -DNAME:STRING=Qt5Core -DCOMPILER_ID:STRING=GNU -DLANGUAGE:STRING=CXX -DMODE:STRING=COMPILE -I/home/wine/newstart/build_script/install-linux/include/ -I/home/wine/newstart/build_script/install-linux/include/QtCore -I/home/wine/newstart/build_script/install-linux//mkspecs/linux-g++ wine@raven ~software/cmake/install-3.0.0-rc3/bin/cmake --find-package -DNAME:STRING=Qt5Svg -DCOMPILER_ID:STRING=GNU -DLANGUAGE:STRING=CXX -DMODE:STRING=COMPILE CMake Error at /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:16 (message): Failed to find GL in with CMAKE_CXX_LIBRARY_ARCHITECTURE . Call Stack (most recent call first): /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:50 (_qt5gui_find_extra_libs) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:141 (include) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:86 (find_package) /home/wine/newstart/build_script/install-linux/lib/cmake/Qt5Svg/Qt5SvgConfig.cmake:86 (find_package) /home/software/cmake/install-3.0.0-rc3/share/cmake-3.0/Modules/CMakeFindPackageMode.cmake:178 (find_package) Qt5Svg not found. CMake Error: Problem processing arguments. Aborting. I got identically bad results for Qt5Gui and Qt5PrintSupport (the other two components used by PLplot). So it appears the only component that currently works for CMake-2.8.12.2 and CMake-3.0.0-rc3 is Qt5Core. This was for a Qt5-5.2.1 that I built myself (see details of the configuration of that build in the other thread). Could you try the above two commands for yourself to confirm (or not) whether the above issue is a general one or specific to my particular Qt5 build? If it is a specific problem for my Qt5 build, and you have a recommendation to change that build so that --find-package works properly for me, that would be extremely helpful. However, if you discover the problem is a general one for --find-package and Qt5, then it appears that Qt5 might be a good illustrative example to use for your renewed effort at developing a reliable --find-package
Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)
On Wednesday, April 23, 2014 09:22:09 Alan W. Irwin wrote: On 2013-10-19 20:16+0200 Alexander Neundorf wrote: On Thursday 17 October 2013, Stephen Kelly wrote: Brad King wrote: On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. A new, similar --find-target mode or similar may be more appropriate: cmake --find-target --package Qt5Widgets --target Qt5::Widgets ... # KF5Config exports 3 independent targets: cmake --find-target --package KF5Config --target KF5::ConfigCore ... cmake --find-target --package KF5Config --target KF5::ConfigGui ... cmake --find-target --package KF5Config --target KF5::ConfigWidgets ... Yes, that will work. And a new command/option is not even necessary. The name of the target could be given as additional option. If none is given, it will use the variables as it does now, if a target is given, it will use this target and its properties. I'll work on that when I find the time (and nobody is faster). How is that going, Alex? I have more or less given up on this. Due to all the changes in cmake recently (not recommending setting variables anymore in find_package(), and all the target property stuff), this would require quite some work, and I seriously don't have that much time for cmake currently. Also, one of the big benefits, not having to read documentation for every package anymore, but having a standard interface, is lost, AFAICS. So, if somebody wants to pick that up, feel free. Sorry Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)
On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)
Brad King wrote: On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES variable (or a slight variation) being set after a successful find_package(Foo): http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the future there will be Find-modules which typically export one of (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that too, and a big number, probably majority, of Config.cmake files, which do not export such variables. The only chance I see would be to simply collect all library targets and return what they provide, but this doesn't feel good. I would have much prefered using a clear interface like the Foo_LIBRARIES variable. Perhaps we need to establish a convention for find modules and package configuration files to interact with --find-package mode. I have no thoughts on the specifics of how that would work though. A new, similar --find-target mode or similar may be more appropriate: cmake --find-target --package Qt5Widgets --target Qt5::Widgets ... # KF5Config exports 3 independent targets: cmake --find-target --package KF5Config --target KF5::ConfigCore ... cmake --find-target --package KF5Config --target KF5::ConfigGui ... cmake --find-target --package KF5Config --target KF5::ConfigWidgets ... Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
