[Dune-devel] Required CMake version

Christian Engwer christian.engwer at uni-muenster.de
Thu Jan 4 12:12:16 CET 2018


Hi Dominic,

thanks! This finally answers the question, where the problem was/is.

Christian

On Thu, Jan 04, 2018 at 11:54:50AM +0100, Dominic Kempf wrote:
> Hey everybody,
> 
> I was a bit silent about this during the last days, as I do not care as
> much about the CMake requirements
> (in one direction or the other actually). But I would like to give some
> input as to why we proposed a higher
> CMake requirement a while ago:
> 
> The dune enable all packages feature only works partially with cmake lesser
> than 3.1.
> In fact it currently errors out under some circumstances:
> https://gitlab.dune-project.org/core/dune-common/blob/master/cmake/modules/DuneEnableAllPackages.cmake#L275
> Although only Dune modules that build libraries and link executables
> against these are affected,
> we considered it cleaner to just raise the CMake bar.
> 
> After all, I think that the enable all packages feature has brought quite a
> bit of convenience for our users -
> I havn't seen a bug report/mailing list question that could be solved by
> call dune_add_mpi_flags ever since its introduction.
> Before those happened several times a year.
> 
> I hope that helps a fact-based discussion of the topic,
> Best,
> Dominic
> 
> On Thu, Jan 4, 2018 at 11:12 AM, Christian Engwer <
> christian.engwer at uni-muenster.de> wrote:
> 
> > Dear Christoph,
> >
> > Thanks for partially answering my questions :-)
> >
> > I start with one further important question:
> >
> > > What is dangerous, if dune-common requests 3.1 but downstream modules
> > > use 2.8.12. Then CMake is in the wrong mode and will interpret things
> > > differently. That is what we called "subtle bugs".
> >
> > what happens if downstream modules impose higher requirement? Is this
> > also dangerous?
> >
> > This is what happened before and this was one of the arguments to jump
> > to the newer version. Following this argument, dune-core would loose
> > control over which version to require.
> >
> > and then to your answers
> >
> > > 2) Steffen and Dominic found some bugs in older CMake version, and they
> > > wished to switch to CMake 3.1 already in 2015. Having the switch with
> > > Dune 2.6 seems reasonable.
> >
> > again this is extremely vague. If we had specific cmake code, which is
> > necessary to work around bugs in cmake < 3.1 and is hard to maintain I
> > would have guessed, that someone updates this code, but this has not
> > happened.
> >
> > As such changes didn't happen for 2.6, I think Markus question,
> > whether 3.1 is necessary, is totally reasonable. This does not imply
> > that we need to switch back to 2.8, but asking this question should
> > not be problem. And "we decided this" is not a proper answer.
> >
> > Best
> > Christian
> >
> >
> > _______________________________________________
> > Dune-devel mailing list
> > Dune-devel at lists.dune-project.org
> > http://lists.dune-project.org/mailman/listinfo/dune-devel

-- 
Prof. Dr. Christian Engwer 
Institut für Numerische und Angewandte Mathematik
Fachbereich Mathematik und Informatik der Universität Münster
Einsteinstrasse 62
48149 Münster

E-Mail  christian.engwer at uni-muenster.de
Telefon +49 251 83-35067
FAX     +49 251 83-32729




More information about the Dune-devel mailing list