What, specifically, do you mean by "remove sibling build feature"?
Will we no longer support having multiple opm-${module} directories checked out
in a single directory, do (more or less) active development on all of them and
have the build output in a completely separate tree? I don't care if it's
difficult, I care if it will be possible at all.
I currently use the following setup for my build and performance tests:
* OPM modules checked out in path/to/src/opm/opm-${module}
* Third-party packages (notably the ERT) checked out in
path/to/src/3rdparty/${package} and installed in
path/to/inst/{seq,mpi}/{dbg,opt}/${package}
* All OPM modules built in subtrees of path/to/build/opm/${config} in which
${config} denotes sets of variable decisions, e.g., which Dune version to
target, whether to build in debug or release mode, whether or not to include
MPI support and so on.
The main benefit of this setup is that I get separation of concerns and can
check multiple conditions with a single source tree. Roland's code that looks
for build output in sibling directories of the current module's build tree and
build input (i.e., source code) in sibling directories of the current module's
source tree makes this setup very easy to use and I'd prefer not to lose the
ability to use the build system this way.
Bård
________________________________
From: Opm [[email protected]] on behalf of Joakim Hove
[[email protected]]
Sent: 21 May 2015 00:17
To: [email protected]
Subject: [OPM] Installation sub directories
Hello;
after merging the opm-cmake Pull Requests I am now in the process of trying to
simplify the build system in opm-cmake. Currently my focus is on removing the
sibling-build features.
Much of the build system is permeated by the assumption that the different
modules are in ${module} subdirectory, i.e. if we invoke cmake as:
cmake –DOPM_ROOT=/path/opm
The build system will search for headers and libraries of opm-core in:
header-search : /path/opm/opm-core/include/{…}
library-search : /path/opm/opm-core/lib64/{…}
Whereas when the opm modules are installed with ‘make install’ they will go to:
header-install : ${CMAKE_INSTALL_PREFIX}/include/{…}
library-install : ${CMAKE_INSTALL_PREFIX}/lib64/{…}
I.e. the module subdirectory is absent. My suggestion plan is that:
1. The implicit ${module} subdirectory is removed from the eventual
search path – if you invoke cmake with –DOPM_ROOT= cmake will search for
headers and libraries in ${OPM_ROOT}/include and ${OPM_ROOT}/lib64 respectively.
2. If you want to employ a different version of one the modules you can
invoke cmake as:
cmake –DOPM_ROOT=/default/root
-DDUNE_CORNERPOINT_ROOT=/special/dune-cornerpoint
The use of module subdirectories is not strictly bound to sibling builds; but
they certainly simplify sibling-build search semantics. Dune also seems to have
these directories.
Any opinions on this? Are there some fundamental issues with the use of module
subdirectories which I have overlooked?
Joakim
RDI project with IT elements -> Contact R&D
Toolbox<https://statoil.service-now.com/selfservice/catalog_item_detail.do?sysparm_document_key=sc_cat_item,78bfbbce6fb455001f6446916e3ee453>
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
