[cmake-developers] [CMake 0012591]: FIND_PACKAGE(Boost 1.45.0 COMPONENT mpi REQUIRED) can't find boost_mpi library
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=12591
==
Reported By:Andrew Prokhorenkov
Assigned To:
==
Project:CMake
Issue ID: 12591
Category: CMake
Reproducibility:always
Severity: block
Priority: normal
Status: new
==
Date Submitted: 2011-11-24 11:53 EST
Last Modified: 2011-11-24 11:53 EST
==
Summary:FIND_PACKAGE(Boost 1.45.0 COMPONENT mpi REQUIRED)
can't find boost_mpi library
Description:
Problem of finding boost::mpi due to they are, by default, placed not into the
/usr/lib directory.
Steps to Reproduce:
Steps to Reproduce:
1. Install cmake, boost and one of the MPI software (can be mpich2, openmpi or
other).
2. Install boost-mpich2 or boost-openmpi with dependencies.
3. Try to compile some code using boost::mpi with next CMakeLists.txt:
ADD_EXECUTABLE(mpi-test test.cpp)
FIND_PACKAGE(Boost 1.47.0 COMPONENTS mpi serialization REQUIRED)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(mpi-test ${Boost_LIBRARIES})\
4. cmake . won't find library:
The following Boost libraries could not be found:
boost_mpi
Additional Information:
SET(BOOST_ROOT /usr/lib/mpich2/) or, other, for different architecture and
MPI software can be a solution. But, it isn't portable, and, looks like, it
this (/usr/lib/mpich2/lib or /usr/lib/openmpi/lib) path is standard and correct
- FindBoost.cmake from cmake package should find it by itself. Without any
user-defined paths.
==
Issue History
Date ModifiedUsername FieldChange
==
2011-11-24 11:53 Andrew ProkhorenkovNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
On Wednesday 23 November 2011, David Cole wrote:
On Wed, Nov 23, 2011 at 2:09 PM, David Cole david.c...@kitware.com wrote:
On Wed, Nov 23, 2011 at 2:03 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 11/23/2011 12:51 PM, Brad King wrote:
On 11/23/2011 12:48 PM, Brad King wrote:
On 11/23/2011 12:43 PM, Brad King wrote:
On 11/23/2011 12:34 PM, Alexandru Ciobanu wrote:
The regex in question is:
^[^][:/*?]+\$
To include a literal ] in the list, make it either the first item
It must be the [: in this regex that TRE sees as special since it
allows expressions like [:digit:] inside a bracket expression.
Still, this is a case that my proposed policy would pick up.
-Brad
I am still very wary about this policy. For 99% of folks the current
regex is just fine. Making them eventually change to get the new
regex is making them do work that they don't need or want. I would
rather have two API's. I just don't see the big upside of TRE, and I
see this causing pain for lots and lots of folks if we push them to
make the change. CMake has most likely 100,000 or more users at this
point. A change like this could easily inflict a man years of effort
onto the world, and should not be taken lightly.
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Big upside:(quoting from Alexandru Ciobanu's email of Nov. 17th
earlier in this thread)
The impact on the build time is pretty dramatic:
CMake: 7h39m
CMake + TRE: 1h06m
And although there is a big upside, we do still have to be careful.
We have to remember that regexes are used in the context of ctest -D
invocations, ctest -S script running and cmake -P running, too, where
policies are not really a reliable mechanism. So in addition to having
a careful policy, we also have to decide what to do in those cases.
The case that is in question here for the big performance gain is
ctest running and filtering build output based on regexes. No cmake
policy mechanism in sight for that scenario.
Also, AFAIK supports more stuff than the current regexps. This is good.
But doesn't that mean that potentially there could be regexps existing which
right now don't have a special meaning, but with TRE they suddenly get a
special meaning and change the matching ?
Does e.g. the following produce the same result ? I get : as match here.
set(text hello world [:digit:])
if (${text} MATCHES .+([:digit:]))
message(STATUS match: \${CMAKE_MATCH_1}\)
endif()
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
On Thursday 24 November 2011, Stephen Kelly wrote:
Hi there,
I am working on installing CMake config files from the Qt repository so
that there is less need for a FindQt.cmake.
The motivation is that between releases of Qt and CMake, the features of Qt
get out of sync with the features available through FindQt.cmake, but with
config files that is not the case. Additionally, as the Qt buildsystem
knows everything about the package it is creating, it is possible to
create config files that already 'know the answers' and locations of
everything without having to find+query.
The previous discussion on this is here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2090
the current candidate for inclusion in Qt is here (which requires an
account in the Qt jira):
http://codereview.qt-project.org/#change,8518
and here (which does not):
https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-
qtbase/commit/913fd3a1acffbae2ca8f6967dd951a03ff9f76a4
There is a small sticking point to this being in a finished state:
In creating the imported targets, I attempt to create the same content as
cmake creates when using install(EXPORTS). So I generate something along
these lines:
get_filename_component(_qt5_install_prefix
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
set_property(TARGET Qt5Core APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
set_target_properties(Qt5Core PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG
IMPORTED_LOCATION_DEBUG ${_qt5_install_prefix}/lib/libQtCore.so.5.0.0
IMPORTED_SONAME_DEBUG libQtCore.so.5
)
set_property(TARGET Qt5Core APPEND PROPERTY IMPORTED_CONFIGURATIONS
RELEASE) set_target_properties(Qt5Core PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE
IMPORTED_LOCATION_RELEASE
${_qt5_install_prefix}/lib/libQtCore.so.5.0.0
IMPORTED_SONAME_RELEASE libQtCore.so.5
)
That is, I generate the full file name for the IMPORTED_LOCATION including
the library prefix and suffix, which are also used for the IMPORTED_SONAME.
QMake does not provide the library prefix and suffix used in variables, as
cmake does, but I believe there is also no way to change them in qmake. As
a result I hardcode the prefixes and suffixes for windows/linux/max -
.dll, .so etc.
The Qt QMake maintainer does not like this, and requests that CMake
determines the prefix and suffix instead. Does CMake provide any way for me
to get the default prefix and suffix for libraries? If it does then I could
generate something like this instead:
IMPORTED_SONAME ${CMAKE_LIBRARY_PREFIX}QtCore.${CMAKE_LIBRARY_SUFFIX}.5
It's CMAKE_(STATIC|SHARED)_LIBRARY_(SUFFIX|PREFIX) .
But I still don't think it's necessarily a good idea or the right change to
make. QMake and CMake don't necessarily agree on what the prefix and suffix
for libraries will be on different platforms for one thing.
Yes, it would be the wrong source of information. This information must come
from the one who creates libraries, not from the one who wants to know how
they are named.
What would you consider a good idea?
Could this have any implications for cross-compiling?
Currently I generate IMPORTED_CONFIGURATIONS for debug and release
(conditionally, depending on how Qt is built). Should I also generate code
to set target properties for no configuration? Or should I only do that,
and not have debug/release versions?:
Having a debug configuration is a good thing I'd say.
Additionally having a release or noconfig version should be fine.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
