Date: Wed, 26 Aug 2015 11:42:34 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: Mathieu Arnold <mat@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r395079 - in head/graphics: . mitsuba mitsuba/files Message-ID: <20150826114234.GA78599@FreeBSD.org> In-Reply-To: <20150824102328.GC93486@ivaldir.etoilebsd.net> References: <201508230856.t7N8uwal009338@repo.freebsd.org> <96D957F8044D8B647B259802@atuin.in.mat.cc> <20150824070915.GA15244@FreeBSD.org> <20150824084807.GA93486@ivaldir.etoilebsd.net> <20150824090104.GB93486@ivaldir.etoilebsd.net> <20150824094539.GA77434@FreeBSD.org> <20150824102328.GC93486@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 24, 2015 at 12:23:29PM +0200, Baptiste Daroussin wrote: > On Mon, Aug 24, 2015 at 09:45:39AM +0000, Alexey Dokuchaev wrote: > > I've thought of Uses/compiler.mk, but eventually couldn't decide which > > compiler to ask for: the problem in my case was not with the code (so it > > is not like "port needs a compiler understanding C++0X/C++11/C++14", but > > the bugginess of GCC 4.2.1 itself. (Now that I'm reading through it > > again, compiler:openmp looks interesting). > > > > Or there's a way to require a modern compiler thish is not feature-based? > > Not yet, but could be added, I would add compiler:c11 in your case (even > if you are not requiring c11 itself.) Well OK, but using "compiler:c11" can be potentially confusing for C++ software. Looks like we need something like compiler:gcc42_too_old for cases like this. :) On Mon, Aug 24, 2015 at 10:53:48AM +0200, John Marino wrote: > Not to mention that it's pointless to support earlier than officially > supported platforms because everyone else is ripping out support every > time they touch a port and see it, actively. In some cases, the only > change in the commit is removing support. [EOL means EOL.] Yeah, I'm worried about this. I have nothing against removing actual cruft -- e.g., BROKEN_FreeBSD_8 statements since they are not really breaking anything, just making Makefiles cleaner and easier to maintain. Yet I believe it's better to discuss with maintainers when removing the actual support. Maybe it looks different for those OSX-on-their-laptop developers, but having all my gear FreeBSD based it usually always an unfortunate moment to upgrade. People also might argue that breaking ports will urge dumb users like myself to upgrade faster. While this has some merit, let's not forget that EOLing the release will cause ports to break by themselves, and forcing things does not really change much in the long run, but annoys users a lot: no one likes them things are forcibly broken rather then being let die teethless in their bed. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150826114234.GA78599>