On 05/21/2015 09:06 AM, Joakim Hove wrote:
Maybe it was me who misunderstood it, but my view is that the opm-cmake
based build system in it current form uses almost the same approach as
the one used for the 2015.04 release. The only difference is that the
build system is in a single centralized (and thus much more easily
maintainable) place instead of having all its files verbatimly copied to
all repositories (or sometimes not, which is the cause of much of the
hilarity which was to be had with the build system before opm-cmake).
That is 100% correct.
Although I'm currently over_obligated on a dense matrix/clustering
problem; I personally am very excited about these developments in OPM.
I'm not sure when I'll return to OPM (gentoo ebuilds creation) but it
looks like most of the packaging and restructuring is well under way to
set this up now, properly, with gentoo ebuilds.
THANKS to ALL that made this a reality!
As far as I see it, opm-cmake is thus the first step of the build system
refactoring. Step two is to make the build system federated, i.e., it
becomes possible to ship the build system parts which are specific to an
OPM module with only the affected repository itself, i.e., no copies
would be needed anymore and no "central" repositories would need to be
bugged if something changes in these parts.
Well – now I am a bit uncertain; as I see it step is 2 removing the
sibling build feature; for two reasons:
1.In my opinion the whole concept of sibling builds is unnecessary
complicated – potentially creating problems with installation++ I
realize opinions differ on this.
2.The sibling builds contribute significantly to the complexity of the
whole system – essentially leaving it in “Don’t touch it” deadlock.
If I understood Joakim correctly, the sibling build feature is the prime
blocker for step 2. (I could be wrong, though.)
Well – that might be stretching it. I really so not see what it takes to
get to a fully federated build, or if it is at all possible. But
reducing the complexity in the system will certainly make it simpler to
see a way.
In gentoo ebuilds (scripts that basically build out from downloadable
source repositories) the different inter related modules can have all
sorts of conditionals on the other relevant modules with version
numbering for both compile time and runtime dependencies.
Blender is an good example to see verbose usage of 'cmake' and it is
online for easy viewing [1], as are all gentoo (tree) sources, to get
ideas for solutions of building from sources. A general gentoo reference
for categorized ebuilds (scripts to build from sources) is found here [2].
'Epatch_user' is ground breaking in that it allows for anyone to test
code (patches) easily with the latest source builds; so as to greatly
improve the joy users experience with customizations to meet their
exact needs. It also provides a mechanism to facilitate/ensure robust
testing of the patches against the latest published sources before
formal submittal [3].
What is possible using the ebuild (scripting) semantics is mostly
documented in the gentoo 'devmanual' [4]. The section on dependencies
is relevant reading for some ideas how to solve these problems for OPM
[5]. My sincerest hope is that these resources yield ideas for the
greater OPM development community.
hth,
James
[1]
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-gfx/blender/blender-2.72b-r2.ebuild?revision=1.1&view=markup
[2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
[3] https://wiki.gentoo.org/wiki//etc/portage/patches
[4] https://devmanual.gentoo.org
[5] https://devmanual.gentoo.org/general-concepts/dependencies/index.html
_______________________________________________
Opm mailing list
Opm@opm-project.org
http://www.opm-project.org/mailman/listinfo/opm
