[Dune-devel] Compiler requirements
Carsten Gräser
graeser at mi.fu-berlin.de
Thu Oct 5 16:17:44 CEST 2017
Hi,
Am 05.10.2017 um 15:43 schrieb Markus Blatt:
> Hi,
>
> I am actually a bit tired of this discussion, but anyway.
the discussion is indeed tiring. Hence I'll only give keywords
but no details for the reasons to use maintained (they are not
even new) compilers:
* more bug fixes in compilers
* better code generation
* faster compile times
* less fallback code to maintain in dune
* modern language features
-> cleaner code, simplified interfaces,
new dune features not possible otherwise
For those who develop/need new dune features, doing this
with old compilers is increasingly complicated. Those
who don't need these new features, can rely on our tested
old releases.
Best,
Carsten
BTW:
I'm surprised that even gcc 4.8 comes up again.
It's more than two years ago that we decided
to stop supporting this. And none of the users
complained during this time.
>
> On Tue, Sep 19, 2017 at 09:13:40PM +0200, Christoph Grüninger wrote:
>> having GCC 5.1 and CMake 3.1 seems reasonable to me.
>>
>> Anything beyond that might be too progressive. Let's have an official
>> vote. I like to hear the opinion of Markus and Robert. Further, we
>> should ask our users. What kind of Red Hat is Alf and the OPM project
>> currently using?
>>
>
> It is obvious that I am no big fan of progessively raising compiler
> requirements (I still use Debian jessie). If we do this too fast, then
> we loose some of our valuable downstream testers. I do think that this
> is not in our best interest.
>
> In OPM we are just aiming at officially supporting DUNE 2.5, because that
> is the default version in Debian. As differences are not very large to the
> upcoming 2.6 release we probably could use OPM for testing the release. If
> the compiler requirements are increased, this might be too much work
> and we will simply not do it.
>
> Currently we are experiencing problems with the grid tests which are
> using a bit too much TMP for my taste, and test things they should not
> test. CpGrid has no codim-1 entities and does not always use the
> interface/engine classes. Yet one test assumes that at
> least one codim-1 entity exists for every element. The full geometry
> interface for vertices is tested (jacobians, center, volume) and I am
> not sure whether that makes
> sense. https://github.com/OPM/opm-grid/pull/284 In our case we always
> assumed using some of them are programming errors. We cannot do that
> anymore.
>
> Redhat collaborators use gcc 4.9, but might be able to use newer ones
> with Developer Tools. Ubuntu collaborators still hold us back on gcc
> 4.8, though. We do our testing on Debian stable and just switch to the
> new one last week.
>
> On the one hand I agree that supporting Ubuntu LTS for the full life
> time (i.e. 14.04 with gcc 4.8(?) until 2019) might be overkill. On the
> other hand if there is no good reason to switch why should we limit
> the resource of human testers? If there is a good reason and we make
> that clear then even some Ubuntu LTS users might be willing to jump to
> newer versions.
>
> So what are these good reasons again (besides the usual its new, its
> cool, and I want to use it?
>
> https://www.ubuntu.com/info/release-end-of-life
> To the very least Ubuntu LTS should be supported during the hardware
> maintainance period. Maybe even for 1 additional year. Same for Debian
> stable version.
>
> Just my 2 cents.
>
> Markus
>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at lists.dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel
>
--
Prof. Dr. Carsten Gräser
Freie Universität Berlin
Institut für Mathematik
Arnimallee 6
14195 Berlin, Germany
phone: +49 30 838 72637
fax : +49 30 838 472637
email: graeser at mi.fu-berlin.de
URL : http://page.mi.fu-berlin.de/graeser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20171005/53a6be27/attachment.sig>
More information about the Dune-devel
mailing list