[Dune] first release candidate for 2.6 release

[Andreas Dedner]

This was done through dune-common MR323

https://gitlab.dune-project.org/core/dune-common/merge_requests/323

There was brief discussion but nobody! was arguing that this requirement
was too strict - only some people suggestion to go further (3.5).
Why those worried about this type of restriction don't follow and don't
get involved in these discussions is beyond me. I couldn't find the
exact dates but it seemed to have been open for some time (a month
even?). One can argue that the description of the MR doesn't really
state the rational behind the change but then that could have been asked
in the MR at the time...

Btw: If we change the requirements, we need to set up a docker
container based on cmake 2.8.12 and the lowest supported g++
version. There should always be a 'minimum' or 'oldest' image
used in the CI testing.

On 03/01/18 14:18, Steffen Müthing wrote:
> 
>> Am 03.01.2018 um 15:05 schrieb Christian Engwer <christian.engwer at uni-muenster.de>:
>>
>> On Wed, Jan 03, 2018 at 02:49:02PM +0100, Markus Blatt wrote:
>>> On Wed, Jan 03, 2018 at 02:37:25PM +0100, Markus Blatt wrote:
>>>
>>>>> * dune-functions requires CMake 2.8.12. Dune common 2.6 will require
>>>>> CMake 3.1.
>>>>
>>>
>>> Here is the complete picture of the requirements:
>>>
>>> dune-alugrid/CMakeLists.txt:cmake_minimum_required(VERSION 2.8.12)
>>> dune-common/CMakeLists.txt:cmake_minimum_required(VERSION 3.1)
>>> dune-geometry/CMakeLists.txt:cmake_minimum_required(VERSION 2.8.12)
>>> dune-grid/CMakeLists.txt:cmake_minimum_required(VERSION 2.8.12)
>>> dune-istl/CMakeLists.txt:cmake_minimum_required(VERSION 2.8.12)
>>> dune-localfunctions/CMakeLists.txt:cmake_minimum_required(VERSION
>>> 2.8.12)
>>> dune-python/CMakeLists.txt:cmake_minimum_required(VERSION 3.1)
>>> dune-uggrid/CMakeLists.txt:cmake_minimum_required(VERSION 2.8.12)
>>>
>>> Markus
>>
>> apparently dune-common bumped the requirements, but I can't find a
>> commit that would actually require the change, except for
>>
>> commit bcf85fe4aef2edaefecbfe8f4eb626606c93826a (refs/merge-requests/323/head, refs/keep-around/bcf85fe4aef2edaefecbfe8f4eb626606c93826a)
>> Author: Christoph Grüninger <gruenich at dune-project.org>
>> Date:   Thu Sep 28 23:42:00 2017 +0200
>>
>>    [CMake] Drop backported code from CMake 3.1
>>
>> which just removed compatibility code.
>>
>> Sure, it is better to rely on upstream code, but I agree, that it
>> would not have done much harm to stick to 2.8.12. The situation might
>> be different for dune-python, but this should not be an argument for
>> the core modules.
> 
> OTOH, CMake 2.8 in particular has a whole bunch of weird little bugs and subtle
> differences from CMake >= 3.1 (not accepting keyword arguments in some places where
> later releases will flag a deprecation warning if you leave them away for example). And configuring
> different modules at different compatibility levels is just an invitation for horrible small problems, mostly
> because our downstream modules all re-run the CMake code of upstream modules.
> 
> I really don’t see what platforms are still stuck with such an ancient CMake and don’t run
> up against our compiler requirements…
> 
> Steffen
> 
>>
>> Best
>> Christian
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at lists.dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>>
> 
> 
> 
> _______________________________________________
> Dune mailing list
> Dune at lists.dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20180103/3b351280/attachment.sig>