[] 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.
Well - I'll take your word for it; but I still insist there must be some
21. mai 2015 kl. 09:58 skrev Joakim Hove jo...@statoil.com:
Hello;
thank you for your input.
What, specifically, do you mean by remove sibling build feature?
With that I mean that when searching for opm libraries and header files the
build system will not use heuristics to look in
I use a setup similar to Bård, where all the module repositories' are
cloned into sub-directories of a src/ folder, and then all the builds
are done (truly) out-of-source into a similar cousin sub-directories
of a build/ directory.
What I like about this solution is that I can edit and
I use a similar setup as Bård, and I am also reluctant to abandon the so-called
sibling builds.
Having heard that various meta-project will solve the same, I am willing to try
them out, what
should I be using instead?
My main concerns are that:
- it must not be too hard to make a developer's
Hi,
On Thursday 21 May 2015 08:54:18 Alf Birger Rustad wrote:
First of all, I also want to thank Joakim for bringing up the discussion
before making changes. My thoughts are as follows:
Currently my focus is on removing the sibling-build features.
This was discussed at the OPM meeting,
of the build trees). This
feature is *very* convenient for build testing.
Bård
From: Opm [opm-boun...@opm-project.org] on behalf of Joakim Hove
[jo...@statoil.com]
Sent: 21 May 2015 13:12
To: opm@opm-project.org
Subject: Re: [OPM] Installation sub
Hi,
On Thursday 21 May 2015 12:45:04 Alf Birger Rustad wrote:
sibling builds make it hard to have a distributed build system, i.e., that
every OPM module ships its own build system modules. In turn, I think
that this is a strict necessity for the buildsystem to be even considered
for
Subject: Re: [OPM] Installation sub directories
This was discussed at the OPM meeting, and my recollection from the discussion
on sibling builds is
-a majority of developers use the feature
-it does not add significant complexity when determining which
libraries/binaries are actually linked
This was discussed at the OPM meeting, and my recollection from the discussion
on sibling builds is
-a majority of developers use the feature
-it does not add significant complexity when determining which
libraries/binaries are actually linked
-it is not a significant maintenance burden to keep
I may be a bit behind on this, but is there special treatment
of directories called 'src' and 'build'? If so, I can see how that can lead to
some confusion []
No - it is not that bad. The src directory will always be ${ROOT}/${module} -
so that is simple. The stem of
-project.org] on behalf of Joakim Hove
[jo...@statoil.com]
Sent: Thursday, May 21, 2015 1:12 PM
To: opm@opm-project.orgmailto:opm@opm-project.org
Subject: Re: [OPM] Installation sub directories
This was discussed at the OPM meeting, and my recollection from the discussion
on sibling builds is
-a majority
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
...@statoil.com]
Sent: 21 May 2015 23:55
To: opm@opm-project.org
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
:17
To: opm@opm-project.org
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
14 matches
Mail list logo
