[CMake] Find*.cmake variable naming

[Mike Jackson]

On Jan 17, 2008, at 5:41 PM, 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.
>
> Hi Andreas,
>
> I've looked at your module. The variable names should be all  
> uppercase.
>
> 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.
>
> Your version doesn't find any library on openSUSE
>
> /usr/lib64/libboost_date_time.a
> /usr/lib64/libboost_date_time.so -> libboost_date_time.so.1.33.1
> /usr/lib64/libboost_date_time.so.1.33.1
> /usr/lib64/libboost_filesystem.a
> /usr/lib64/libboost_filesystem.so -> libboost_filesystem.so.1.33.1
> /usr/lib64/libboost_filesystem.so.1.33.1
> ...
> /usr/lib64/libboost_thread-mt.a
> /usr/lib64/libboost_thread-mt.so -> libboost_thread-mt.so.1.33.1
> /usr/lib64/libboost_thread-mt.so.1.33.1 -> libboost_thread-mt.so
>
>
> The search paths for macports and fink are missing.
>
>>
>> http://www.cmake.org/Bug/view.php?id=6257
>>
>
> This needs to be fixed and needs more testing on different systems  
> before it
> can be included.
>
>>

I am curios how we should be looking for the boost version number?  
Even in the FindBoost.cmake that is included with CMake itself the  
authors are just guessing at the version number.

SET(SUFFIX_FOR_PATH
  boost-1_34_1
  boost-1_34_0
  boost-1_34
  boost-1_33_1
  boost-1_33_0
)

If you have a better way then by all means I would like to see it.  
The only thing I can think of, absent the environment variable  
BOOST_ROOT, is to look in the standard include locations and look for  
"Boost", then look inside that for another include, then parse the  
folder name inside that (boost-1_34_1 in my case) to try and figure  
out what the version is. All that is used later on when constructing  
the name of the boost library and I feel it is needed although I am  
not certain of that.

Even for FindQt4.cmake, the same thing is needed. Some value to help  
cmake find Qt4.

FIND_PROGRAM(QT_QMAKE_EXECUTABLE NAMES qmake qmake4 qmake-qt4 PATHS
   "[HKEY_CURRENT_USER\\Software\\Trolltech\\Qt3Versions\ 
\4.0.0;InstallDir]/bin"
   "[HKEY_CURRENT_USER\\Software\\Trolltech\\Versions\ 
\4.0.0;InstallDir]/bin"
   "[HKEY_CURRENT_USER\\Software\\Trolltech\\Versions\\$ 
{qt_install_version};InstallDir]/bin"
   $ENV{QTDIR}/bin
)

In this case we are looking for qmake. Once we find qmake the rest is  
all inferred based on the location of qmake. Note that we are looking  
in the windows registry or relying on QTDIR being set in order to  
find Qt4 on non-windows systems.

I guess some regex in /usr/local/include or /usr/include might be  
able to automatically find boost....

Just my 2 cents..

-- 
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services