[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: CMake Find Modules, HINTS, and NO_DEFAULT_PATH
From:       Brad King <brad.king () kitware ! com>
Date:       2008-06-10 23:52:25
Message-ID: 484F13B9.30600 () kitware ! com
[Download RAW message or body]

Alexander Neundorf wrote:
> On Monday 09 June 2008, Brad King wrote:
>> Hi Folks,
> ...
>> The solution I've committed to CMake HEAD in CVS is to distinguish
>> "hint" paths from "guess" paths.  For compatibility the PATHS option
>> must continue to mean "guess".  I've added a new HINTS option that is
>> interpreted as "hint" paths.  This allows the above code to be written
>>
>>   find_library(FOO_LIB foo HINTS ${BAR_TOLD_ME_FOO_MIGHT_BE_HERE})
>>
>> The provided hint is preferred over system locations but not over the
>> cmake-specific user environment variables or cache entries.  I've
>> already converted most of the Find* modules provided by CMake to take
>> advantage of this feature.
> 
> Nice :-)

Thanks.

> Minor nitpicking: how about naming that "PREFERRED_PATHS" instead of "HINTS" ?
> This may make the meaning even clearer without having to read the docs.

IMO the name "HINTS" is concise and exactly names the purpose of the
paths it lists...they are hints we got from something else.  Ken Martin
and I considered several names before choosing it.  The word "PREFERRED"
begs the question "how strongly preferred?" which requires reading the
docs anyway.

Given its semantics, a better name for the "PATHS" option would be
"GUESS" or "GUESSES", but I don't want to add confusion by changing
existing options.

-Brad
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
[prev in list] [next in list] [prev in thread] [next in thread]