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 src/ and build/ folders. So
when looking for opm-core the build system will look in ${OPM_ROOT}/lib and
${OPM_ROOT}/include, alternatively default directories like /usr.
My main concerns are that:
- it must not be too hard to make a "developer's install" (although it can be
harder than a "user's install")
I don't really understand what you mean with "developer's install"; do you mean
the process of setting up your development environment such that you can easily
update and build the different modules, and get a final working (developer)
executable based on all the checked out code? As for difficulty - see my
comments below.
- that install must contain only a single working directory for any module
(that then can be used to build all configs desired)
Yes - absolutely
- our current install docs (while outdated in the face of opm-cmake) assume a
sibling build
Yes - I will update that in the face of opm-cmake, and maybe further.
Also: what is the purpose of removing this? What are the user errors we are
trying to prevent? How significant is the simplification of the build system
that will result? I know we discussed this at the OPM meeting a few months ago,
but I'd like to know the motivation behind this a little better.
My experience is that the effective find rules of the build system are quite
opaque; I have had numerous experiences where I thought I was including &
linking a module in location /path/to/xxx - but in the end it turned that the
build system had found a build/ & src/ combination elsewhere. I guess the
challenges with the sibling build system are mostly when installing - not in a
pure developer mode. Now - the fact that I am little challenged is maybe no
reason to change the system, but in addition the current find rules are so
complex that I consider the current system very difficult to maintain - it does
work though; so why mess with it?
OK: I fully realize that the sibling build is very convenient for the
developers. The alternative that I have in my head is based on the cmake
feature LIBRARY_OUTPUT_PATH: (untested loose idea):
1. Check out the source modules the way you want.
2. When configuring pass the options -DBUILD_OUTPUT=/path/to/build/output
-DOPM_ROOT=/path/to/build/output (could even sane "sibling-like" defaults here)
3. Make a build target which copies the header files from the source
directory to /path/to/build/output/include
That way no extra install is required, and the downstream modules will locate
the opm dependencies using the same search logic irrespective of whether we are
searching for an installed version of e.g. opm-core, or the build output from a
previous build.
Joakim
-------------------------------------------------------------------
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
