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 cha
