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
__________________________
--
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
