[cmake-developers] Supporting versioned wx-config in FindwxWidgets.cmake

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon Jun 8 11:49:44 EDT 2015


On 2015-06-08 09:19-0400 Brad King wrote:

> On 06/06/2015 01:41 PM, Alan W. Irwin wrote:
>> -    find_program(wxWidgets_CONFIG_EXECUTABLE wx-config
>> +    find_program(wxWidgets_CONFIG_EXECUTABLE wx-config wx-config-3.0
>
> For reference, this was from upstreaming a Fedora patch:
>
> http://www.cmake.org/Bug/view.php?id=15540
>
>> wx-config wx-config-3.0
>>
>> be changed to
>>
>> wx-config-3.0 wx-config-2.9 wx-config-2.8 wx-config
>
> As discussed in the above-lined issue we need the unversioned name
> first because someone could have a custom-built version earlier in
> their PATH and that should be found first.
>
> I've added the 2.9 and 2.8 versioned names here:
>
> FindwxWidgets: Fix find_program call for versioned names
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c969743

Thanks for including 2.8 and 2.9.

However, I notice an apparent order inconsistency is now left in
this module which may not be your intent; the PATH_SUFFIXES are
specified in descending versioned order followed by unversioned as in
my original suggestion for wx-config.  If the decision is to adopt
generic name first for wx-config shouldn't you use that same
convention for PATH_SUFFIXES or is there some reason for PATH_SUFFIXES
and NAMES to have different ordering conventions?

I appreciate that it is possible that old find modules included in
CMake could be all over the map in terms of their ordering
conventions, and you will have to stick to whatever was decided for
each old module for backwards inconsistency.  However, if there is a
preferred versioned/unversioned ordering convention separately or
jointly for PATH_SUFFIXES and NAMES in new find modules could you
please document that somewhere (or point me to that documentation if
it exists)?

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
__________________________


More information about the cmake-developers mailing list