[cmake-developers] cmake --find-package

[Alan W. Irwin]

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.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________