[CMake] Find*.cmake variable naming

Andreas Schneider mail at cynapses.org
Fri Jan 18 16:13:49 EST 2008


Andreas Pakulat wrote:
> On 17.01.08 23:41:54, Andreas Schneider wrote:
>> Andreas Pakulat wrote:
>>> On 14.01.08 23:40:39, Andreas Schneider wrote:
>>>> Rodolfo Schulz de Lima wrote:
>>>>> Hi, I'd like to comment on the Find*.cmake variable naming procedure
>>>>> adopted by cmake. Right now I have to look at some Find*.cmake files to
>>>>> see what are the output variables they create. Some packages create a
>>>>> *_LIBRARY, others *_LIBRARIES, others *_INCLUDE_DIRS and others
>>>>> *_INCLUDE_DIR. The Modules/readme.txt procedure isn't being used for
>>>>> some packages.
>>>>>
>>>>> Also the vast majority creates upcased (is this an adjective?) variable
>>>>> names, BUT Boost and wxWidgets. There two define Boost_FOUND,
>>>>> Boost_LIBRARIES, wxWidgets_FOUND, wxWidgets_LIBRARIES. It should be
>>>>> better if they were BOOST_FOUND, WXWIDGETS_FOUND etc.
>>>> For much better FindBoost.cmake module take a look at
>>> I've just reported a bug for CMake with an updated/combined version of
>>> that FindBoost and the one from Mike Jackson.
>> I've looked at your module. The variable names should be all uppercase.
> 
> No, please read the readme.txt in the modules directory of cmake. The
> first part of the variable should follow the naming style of the
> FindXX.cmake file.

Hi Andreas,

hmm ok, I don't like uppercase and lowercase mixed in the variable name. It
should be just one, lower or upper.

FindQt4.cmake uses uppercase for all variables.

> 
>> I don't think it is a good idea that you *have to define the boost version*.
>> There should be the possibility to define the version but the module should
>> find it, this is what the module is for. If you write Modules always think
>> about user and packagers.
> 
> Uhm, the problem is that there's no way to find the libraries without
> the version number because unfortunately boost puts its version number
> into the library filenames (and some other stuff). 

There is a way. Normally on Linux if you install the devel package you have
libfoo.so which is a symbolic link to the full so name.

> 
> And hardcoding the version numbers into the FindXX.cmake modules is
> really bad as that one is much harder to change (without forking) than
> the CMakeLists.txt in your project.

I don't say that hardcoding them into the FindXXX.cmake is the way to go but
that you always have to define it is the same problem. If you don't provide a
version number then the module should try to find it.

> 
> However I agree that the FindXXX.cmake module needs to be able to
> support a range of version numbers at the same time. So the user can
> specify a list of versions to try.

Yep, see above.

> 
>> Your version doesn't find any library on openSUSE
> 
> Thats an opensuse bug - IMHO, they patched the boost buildsystem or
> renamed the files after building to get at this. 
> 
> Anyway, adding support for not having any suffix is not a big deal :) 

Could you please add it. A CMakeLists.txt for testing would be nice too. Maybe
 we should start to provide some macros for easy testing of FindXXX.cmake modules.

> 
>> The search paths for macports and fink are missing.
> 
> Where do those put their stuff? Note that /usr/lib and /usr/local/lib
> are already being searched due to the removal of the NO_DEFAULT_PATHS. a

It is

/opt/local

and

/sw/local

Maybe they should be added to CMake by default.

> 
> Andreas
> 

Best regards,


	-- andreas

-- 
http://www.cynapses.org/ - cybernetic synapses




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://public.kitware.com/pipermail/cmake/attachments/20080118/0e67b09d/signature.pgp


More information about the CMake mailing list