On Wednesday, April 23, 2014 14:45:45 Alan W. Irwin wrote: > On 2014-04-23 22:40+0200 Alexander Neundorf wrote: > > On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote: > >> On 2014-04-23 13:21-0400 Bill Hoffman wrote: > >>> On 4/23/2014 12:22 PM, Alan W. Irwin wrote: > >>>> 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 capability. > >>> > >>> I recently ran into a project using --find-package and found a > >>> limitation > >>> that could be very problematic. If a find module in CMake uses a > >>> try-compile, or tries to figure out anything to do with the compiler, > >>> this > >>> command will fail. I am not sure there is a good way around this. > >>> Certainly try-compile is not actively discouraged in the CMake Modules, > >>> so > >>> this can be added to any module at any time, breaking --find-package in > >>> the > >>> future. > >> > >> Hi Bill: > >> > >> You cannot use --find-package unless you specify the language. So I > >> assume that --find-package enables the specified language, and, in > >> general, you would think that try-compile would work properly under > >> those circumstances. > > > > No. > > > > It doesn't really enable a language, it only loads a bunch of files to set > > the most urgently required variables. > > Most of it is implemented in CMakeFindPackageMode.cmake > > > > It is basically wrapping a find_package() call, setting up just enough to > > make it succeed usually. > > try_compile() will fail. > > > > My plan was to limit this mode to Config.cmake files only, but as I said, > > due to the changes in CMake this has become too much work, so I won't > > work on that in the forseeable future. > > Hi Alex: > > The question that remains is will --find-package be maintained > indefinitely for CMake-3.x?
I can't guarantee. Since modern Config.cmake files don't follow the old convention of setting a _LIBRARIES and a _INCLUDE_DIRS variable anymore, which is the basic assumption the --find-package feature was based on, I don't really feel motivated to fix this. > As I said, --find-package is the only way > I know how to obtain required compile and link flags for Qt5 at the > present time (assuming the patch for the library name screwup is > accepted for the CMake support files in Qt5, but that is a separate > Qt5 issue compared to whether or not you decide to maintain > --find-package for CMake-3.x). Until I discovered this thread, I had > assumed that the --find-package option would be maintained > indefinitely for CMake so I haven't looked further at other > alternatives yet. > > Assuming you or someone else decides to remove the --find-package > capability now or sometime during CMake-3.x (which from my point of > view makes sense if you are not going to maintain it), I wouldn't object. This is actually the first time I get serious feedback for that feature, I had the impression nobody uses it or considers it useful. 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