On Friday, April 25, 2014 12:10:30 Alan W. Irwin wrote: > On 2014-04-24 22:41+0200 Alexander Neundorf wrote: > > 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. > > Hi Alex: > > I hadn't attempted to use this feature myself up to now because most > of the PLplot build system was implemented long before --find-package > was implemented. But, in general, I think --find-package is an > excellent idea since ideally (assuming try-compile is not used) it > should supply users with the essential compile and link flags needed > for a dependency while relieving them of the burden of figuring out > details of the CMake-based build system for that dependency. That's a > large potential benefit for a typical modern project that might have > say 20 or more dependencies. > > Much earlier in this thread you said the > > following: > > >> 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). > > Since then you have apparently changed your mind about working on this > (which I can completely understand; I also have very limited time I > can work on CMake). But I have one important follow-up question for > you. > > Is it actually straightforward (but tedious) to implement a > translation of target properties into ordinary compile and link flags > without detailed knowledge of which target properties have been used > for a build system, and your only objection to doing such an > implementation is the time it would take? I assume your answer will > be yes because CMake already must generate ordinary compile and link > flags to build targets from whatever target properties have been used. > But that needs confirmation in case I am missing something.
the (C++) part of the code is in cmake.cxx, cmake::FindPackage(). Hopefully it's straight forward, but I can't tell without actually doing it. 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
