[cmake-developers] cmake --find-package

[Alexander Neundorf]

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