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 external projects to be used. > > This sounds like a strong technical reason for abandoning the sibling build. > However, haven't we already left the distributed model when introducing the > opm-cmake repository, or have I misunderstood something?
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). 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. If I understood Joakim correctly, the sibling build feature is the prime blocker for step 2. (I could be wrong, though.) cheers Andreas -- If your text editor can defeat you at chess, it might be a bit overengineered. -- Jon Cruz, reflecting on the power of Emacs.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
