Hi,
I was currently testing this. I have problems linking boost. On my
workstation there are two boost versions: one old (1.33.1) located at
/usr/include and one newer (1.45.0) located at
/project/res/x86_64_RH5/share/opm/boost. I have tried different flags to
link the correct boost library:
1)
CMAKE_FLAGS="-DBOOST_ROOT=/project/res/x86_64_RH5/share/opm/boost
-DSUPERLU_ROOT=/project/res/x86_64_RH5/share/opm/SuperLU_4.0 "
2)
CMAKE_FLAGS="-DBOOST_LIBRARYDIR=/project/res/x86_64_RH5/share/opm/boost/lib
-DSUPERLU_ROOT=/project/res/x86_64_RH5/share/opm/SuperLU_4.0 "
3)
CMAKE_FLAGS="-DCMAKE_PREFIX_PATH=\"/project/res/x86_64_RH5/share/opm/boost;/project/res/x86_64_RH5/share/opm/SuperLU_4.0\"
"
However, none of these work as I get the following error message:
-- Finding package Boost using module mode
CMake Error at
/project/res/x86_64_RH_5/share/cmake-2.8/Modules/FindBoost.cmake:1199 (message):
Unable to find the requested Boost libraries.
Boost version: 1.33.1
Boost include path: /usr/include
Detected version of Boost is too old. Requested version was 1.39 (or
newer).
The following Boost libraries could not be found:
boost_date_time
boost_filesystem
boost_unit_test_framework
No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the
directory containing Boost libraries or BOOST_ROOT to the location of
Boost.
Call Stack (most recent call first):
cmake/Modules/OpmFind.cmake:82 (find_package)
cmake/Modules/OpmFind.cmake:115 (find_and_append_package_to)
CMakeLists.txt:108 (find_and_append_package_list_to)
Any clue about this one?
Lars
On 14. mars 2013 10:40, Markus Blatt wrote:
Hi,
some of you might have noticed that I am preparing an inofficial DUNE
2.2.1 release with support for CMake and some new features of ISTL.
They are now quite stable an I was able to compile
opm-core,omp-porsol, dune-cornerpoint, and opm-upscaling with it.
Still the approach that I used is a little bit orthogonal to the OPM
approach. The dunecontrol script of the cmake branches detects that it
can use CMake to build the opm modules. It therefore directly call
cmake instead of configure. Unfortunately this means that all
--with{,out}-... --{en,dis}able-... get ignored and the external
software will not be found.
A quickfix would be to extract the pathes provided with
--with-<package>=... and simply add them to the CMAKE_PREFIX_PATH
variable. This hopefully ensures that the find_xxx functions succeed
in most cases.
Of course this means on cannot disable features, but
at least for me that is not important. Are there any objections?
Using this approach inside of the handmade configure files might also
reduce the maintainance effort and reduce errors due to missing
--with-<package> treatment in it.
Cheers,
Markus
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
