[cmake-developers] cmake --find-package

[Alan W. Irwin]

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.

Is perhaps the problem that two languages were needed (e.g., C
Fortran) for the package libraries where you encountered the problem
but --find-package only currently allows one language?  If so, that
should be an extremely easy bug to fix.

Another possibility to explain your bad results for one project is
that --find-package might be implemented in a way that needs compiler
information propagated from one CMake environment to another.

For example, to work around bug 9220 so that PLplot won't error out if
some compiler is missing or broken from one of its many different
supported languages, I implemented a small test project that was then
configured with cmake using execute_process to check that a given
language was working.  (This idea for the workaround was suggested by
Dave Cole a long time ago.) However, I keep making a plea for a proper
fix to bug 9220 because propagating compiler information (held
potentially in a large number of different environment variables and
CMake variables for many different computer languages) from the
principal CMake project to the test project is somewhat problematic.
Therefore, I am wondering if that propagation difficulty is the
fundamental issue in the current --find-package implementation as
well?

Note, it turns out that --find-package appears to be working OK for
Qt5 without any try-compile issues.  So if Qt5 configuration does use
try-compile, it is done in a way that works.  Instead, the problem I
discovered with "GL" was due to an incorrect "GL" name in a
find_library search being done with the CMake support files
distributed with Qt5.  So the fix is a simple patch to those support
files to use the correct name of the GL-related library.  For further
details see my recent cmake mailing list post.

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
__________________________