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