I have imported the latest patches to the CMake build system into the
other modules, resolving the conflicts that had accumulated. The result
is a "rollup" pull request in each repository:
opm-core # 323
opm-material # 9
dune-cornerpoint # 41
opm-porsol # 63
opm-upscaling # 71
opm-benchmarks # 20
opm-polymer # 30
opm-autodiff # 23
opm-verteq # 27
After these are applied, all common files in the cmake/ directory should
end up identical. (There are still some extra files in some
repositories, only needed there).
With these changes, there is a better separation between things that are
project-specific and things that are common in the build system. This
makes it possible to have a "patch queue" of changes to the common
parts, which can be pulled into each of the other repos more or less
automatically. (I have a script that can be used as a starting point for
this).
Therefore, I won't be making any more such rollups (nor do I intend to
do much more on the build system in opm-core for that matter), assuming
that each project from now on is individually updated by its maintainer.
I think it should also be considered if maintainers could add such
patches into the repos at their discretion instead of going through a
pull request, to keep the noise down (any discussion has most likely
taken place in the original pull request).
I have kept all individual patches in the rollup, so the 'blame' history
is the same across repositories. The trade-off is that this creates some
noise in the linear history (due to the amount of patches - about 100
currently!).
To minimize disruptions and testing time, I suggest that these rollups
are tested as one piece, and committed more or less atomically. Every
repository builds on my rig (GCC 4.6.3, CMake 2.8.9, Boost 1.48, DUNE
2.2.1), and run the unit tests that are, so I don't expect there to be
large problems for others.
The real value in all of these changes is that it is now possible to try
to build against DUNE 2.3. However, the code in the repositories doesn't
compile currently because of breaking changes that aren't #ifdef'd yet.
I haven't looked into these; other team members are probably more
suited. I suggest these changes are made as separate pull requests
*after* the rollups are processed.
--
Roland.
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
