This is essential if find package modules define imported
targets (usual for modern Cmake). Without this rerunning Cmake another
time in a non-clean build directory will abort with errors if imported
targets are used. E.g. with
```
CMake Error at /home/mblatt/src/dune/opm-2.9/opm-common/cmake/Modules/OpmSatellites.cmake:320 (add_executable):
Target "test_mpiutil" links to target "ParMETIS::ParMETIS" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Call Stack (most recent call first):
CMakeLists.txt:308 (opm_add_test)
CMake Error at /home/mblatt/src/dune/opm-2.9/opm-common/cmake/Modules/OpmSatellites.cmake:320 (add_executable):
Target "test_mpiutil" links to target "QuadMath::QuadMath" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Call Stack (most recent call first):
CMakeLists.txt:308 (opm_add_test)
```
This will result in multiple searches, but this should be rather fast
due their previous results being cached.
With that combination the first search seems to happen in CONFIG mode
but subsequent searches will use MODULE mode. This will result in the
following warning:
CMake Warning at /usr/share/cmake-3.18/Modules/FindBoost.cmake:1187 (message):
New Boost version may have incorrect or missing dependencies and imported
targets
Call Stack (most recent call first):
/usr/share/cmake-3.18/Modules/FindBoost.cmake:1311 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake-3.18/Modules/FindBoost.cmake:1919 (_Boost_MISSING_DEPENDENCIES)
cmake/Modules/OpmFind.cmake:135 (find_package)
cmake/Modules/OpmFind.cmake:230 (find_and_append_package_to)
cmake/Modules/OpmLibMain.cmake:83 (find_and_append_package_list_to)
CMakeLists.txt:222 (include)
Also the variable Boost_LIBRARIES will look quite messed up by
occurrences of optimized and debug:
Boost_LIBRARIES=optimized;/usr/lib/x86_64-linux-gnu/libboost_system.so.1.74.0;debug;/usr/lib/x86_64-linux-gnu/libboost_system.so;optimized;/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.74.0;debug;/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so
Which will make the modules unusable because of CMake errors during
linking:
CMake Error at /usr/share/dune/cmake/modules/DuneMacros.cmake:991 (target_link_libraries):
The "debug" argument must be followed by a library.
Call Stack (most recent call first):
src/CMakeLists.txt:2 (target_link_dune_default_libraries)
-- Configuring incomplete, errors occurred!
Note this fix is only needed for Boost versions 1.70 and higher.
Older versions do not provide cmake package configuration
files (BoostConfig.cmake) and hence there can be no mixup.
Note also that the alternative approach of setting
CMAKE_FIND_PACKAGE_PREFER_CONFIG does not work for OPM as with this
e.g. the Dune module versions would not be set correctly.
When using CMAKE_DISABLE_FIND_PACKAGE_<name>=ON for a required package
CMake did not issue an errors since we never trigger the find_package
call. With this commit we now check whether such package is required
and send an error.
Otherwise we will never search for e.g. Boost multiple
times and the upmost module in the hierarchy will dictate
the components to be used. That does not work for downstream
modules.
Therefore with this change we check whether there is an argument
COMPONENTS passed to find_package and make sure there will be
another call to it if that is the case.
use pure config mode.
we no longer compile a test application for the libraries,
however checks have been tightened by making sure version of
all opm modules are the same.
this allows for putting prereqs directly in the module repositories
As opm-common is search in the toplevel CMakeLists.txt of each module in
config mode and the dependencies and defines are only processed in
opm_find_package(opm-common), we allow a second search using module mode
to trigger opm_find_package.
Otherwise some defines and macros will not be set as this is done
in opm_find_package. This might also make sense for dunecontrol
which always will set *_DIR.
Even though people are telling that ecl is already found using
sibling search it turned out that this statement is false. It
was always found using the CMake package cache. When installing
this lead to the installed package using ecl from the build tree.
With this commit we first try to find ecl without the package cache
but maybe using sibling search. Building installed packages no works
by setting -DSIBLING_SEARCH=Off -DCMAKE_INSTALL_PREFIX=/install/path
