[Dune] first release candidate for 2.6 release

Steffen Müthing steffen.muething at iwr.uni-heidelberg.de
Wed Jan 3 15:18:25 CET 2018


> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20180103/19c82b21/attachment.sig>


More information about the Dune mailing list