Thanks a lot for those answers.
They mesh more or less perfectly with the gist of my initial assessment. I
will think about the implications a bit more before I make any further comments
except on one technical comment concerning sibling builds. Sibling build trees
do not need to be in a location relative to the source trees and do moreover,
not have to have the same name for all modules.
I'll repeat once more that, in the context of build tests, I use git clones
checked out in ${SRC}/opm-${module}:
$ ls ~/work/opm/src/opm
dune-cornerpoint opm-benchmarks opm-material opm-porsol
eigen3 opm-cmake opm-parser opm-upscaling
opm-autodiff opm-core opm-polymer opm-verteq
and have the same directories in a separate ${BUILD} tree structure,
$ ls ~/data/opm/build/opm/opt/seq/dune-2.3.1
dune-cornerpoint opm-benchmarks opm-material opm-polymer opm-upscaling
opm-autodiff opm-core opm-parser opm-porsol opm-verteq
By the way, the ~/work/opm/src/opm source tree is on an SSD since it's
read-mostly information while the ~/data/opm/build/ tree is a large capacity
spinning disk. Configuring this build amounts to doing
modlist="opm-parser opm-core dune-cornerpoint opm-verteq opm-material"
modlist="${modlist} opm-autodiff opm-polymer opm-porsol opm-upscaling"
modlist="${modlist} opm-benchmarks"
SRC=${HOME}/work/opm/src/opm
BUILD=${HOME}/data/opm/build/opm/opt/seq/dune-2.3.1
for m in ${modlist}; do
mkdir ${BUILD}/${m}
cd ${BUILD}/${m}
cmake [configuration options] ${SRC}/${m}
make -j ${N}
done
in which the "configuration options" do not include any source locations for
modules except installed third-party ones (ERT and Dune, in particular).
Like I said, this is very convenient for build tests. That said, my actual
build test script is a more elaborate and complete--mostly due to error
checking and operation timing.
Bård
________________________________________
From: Opm [[email protected]] on behalf of Joakim Hove
[[email protected]]
Sent: 21 May 2015 23:55
To: [email protected]
Subject: [OPM] Installation sub directories
Thank you for the detailed questions – that gives me an opportunity to explain.
But before we delve into technical details:
1. As is probably clear I would like to remove the sibling build support
– but I am by no means hell bent; I will certainly back down at some point.
2. This discussion became quite vocal before I really had much to show
for myself; quite possibly the final outcome might be that I am really not
satisfied with whatever I end up with – and eventually silently crawl back into
my cage. We will see.
Source-directory: With the term source directory I mean the directory
containing an opm module; i.e. when invoking ‘git clone …’ you create a source
directory. For our projects the source directories will be opm-parser/,
opm-core/, …, the might very well be located in a parent directory called
‘source/’ – but that is completely irrelevant.
Build-directory: The build directory is whatever directory you were in when
invoking cmake; typically called ‘build/’.
Sibling-build – my understanding:
1. The different modules are checked out side by side in the filesystem:
$ROOT/opm-parser
$ROOT/opm-core
$ROOT/opm-autodiff
…
2. For each module a build directory is created with ‘mkdir bulild’. The
follow rules apply for the build directory:
a. The must have the same name for each module; i.e. when using build/
for building opm-parser you can not use build-core/ for opm-core.
b. The build directories must be placed in a certain location relative to
the source directory; I am not sure which possibilities exist – but myself I
use ‘mkdir ${opm-module}/build’ – I know there are other possibilities.
When these restrictions are satisfied by the source and build directories the
downstream modules are able to find the headers and libraries of the upstream
modules by poking in the source directories for the headers and the build/
directories for the libraries. My main gripe with this is that the cmake code
to poke in source & build directories is quite different from the cmake code
used to look for installed versions.
My loose (which is currently mainly in my head) consist of two steps:
1. Remove the support for sibling-build; with that I mean remove build
systems ability to look for headers and libraries in source and build
directories. All searching for headers and libraries should follow exactly the
same logic.
2. Provide an alternative which hopefully is equally convenient for the
developers, but simpler in the build system. This alternative is currently just
a very loose plan.
OK - then to Bårds questions:
Suppose that I'm using and making changes to the Git master sources of two or
more OPM project modules (e.g., opm-parser, opm-core, and opm-autodiff). Am I
supposed to "git clone" the source trees as subdirectories of my OPM_ROOT or
are the sources supposed to be placed somewhere else?
Well – if support for sibling builds in the current form has been removed, you
can git clone the different modules all over the place filesystem wise.
Will there be restrictions on where I put my build trees (e.g., must these be
subdirectories of the corresponding source trees)? Can I have multiple build
trees for a single module?
Again – the build directories can be located wherever you like, and you can
multiple build trees for a single module.
Do I have to run "make install" in an upstream module (e.g., opm-core) to have
any changes visible to downstream modules (e.g., opm-autodiff)? […]In short,
what is the use-case you're developing for the OPM build system? Are you
moving towards a work-flow in which "make install" is the only inter-module
communication device for build products (i.e., headers, libraries and/or
executables)?
Yes – after step 1) above “make install” will be the only inter-module
communication model; and to satisfy downstream dependencies you must explicitly
pass –DOPM_ROOT or –DOPM_${MODULE}_ROOT options. I.e. when configuring
opm-autodiff you must inform cmake where you have installed the upstream
modules:
cmake /path/to/source –DOPM_ROOT=/path/install/opm
Now – this will be significantly more explicit than the current sibling build
based approach; the disadvantages are that:
1. The configure step is slightly more convoluted – i.e. you must
information of where the upstream modules are.
2. You must run “make install” before you can continue building
downstream modules.
I guess 2) is the main disadvantage.
Now the alternative suggestion should remove the need for a “make install”
step: Using the cmake variable LIBRARY_OUTPUT_PATH you can tell cmake to put
all generated libraries in an external location. With this we will have three
directories:
1. The normal source directory
2. The normal build directory
3. The LIBRARY_OUTPUT_PATH directory - which can be located anywhere in
the filesystem.
Now the idea would be that all modules, either explicitly or through a default
based on a convention of the relative locations of the source directories, are
configured to output their libraries to a common output directory; i.e.
something like this:
cd opm-parser/build; cmake ../ -DOUTPUT_PATH=/path/output …
cd opm-core/build; cmake ../ -DOTPUT_PATH=/path/output
–DOPM_ROOT=/path/output # I.e. we search for upstream modules in /path/output
Now – the beauty of this (if it works…) is that the search implementation will
be the same irrespective of whether you are searching in an OUTPUT_PATH
directory or if you are searching for a properly installed module. (This would
in addition require a target copying header files to ${OUTPUT_PATH}/include.)
This makes sense?
-------------------------------------------------------------------
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
