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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
