From owner-svn-ports-head@freebsd.org Mon Aug 24 08:54:00 2015 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A33CE9C1362; Mon, 24 Aug 2015 08:54:00 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E88C1219; Mon, 24 Aug 2015 08:54:00 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.20] (178.Red-83-41-29.dynamicIP.rima-tde.net [83.41.29.178]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 7C64443BC5; Mon, 24 Aug 2015 03:53:50 -0500 (CDT) Subject: Re: svn commit: r395079 - in head/graphics: . mitsuba mitsuba/files To: Baptiste Daroussin , Alexey Dokuchaev References: <201508230856.t7N8uwal009338@repo.freebsd.org> <96D957F8044D8B647B259802@atuin.in.mat.cc> <20150824070915.GA15244@FreeBSD.org> <20150824084807.GA93486@ivaldir.etoilebsd.net> Cc: Mathieu Arnold , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Reply-To: marino@freebsd.org From: John Marino Message-ID: <55DADB9C.4070500@marino.st> Date: Mon, 24 Aug 2015 10:53:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150824084807.GA93486@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 08:54:00 -0000 On 8/24/2015 10:48 AM, Baptiste Daroussin wrote: > On Mon, Aug 24, 2015 at 07:09:15AM +0000, Alexey Dokuchaev wrote: >> On Sun, Aug 23, 2015 at 11:43:21PM +0100, Mathieu Arnold wrote: >>> +--On 23 ao??t 2015 08:56:58 +0000 Alexey Dokuchaev >>> wrote: >>> | +# Unfortunately, the code is not GCC 4.2.1 compatible (due to bugs in GCC >>> | +# itself). Try to use system compiler if it is Clang, otherwise fallback >>> | +# to modern GCC (on older versions of FreeBSD). >>> | +.if ${OSVERSION} < 900014 >>> | +USE_GCC= yes >>> >>> OSVERSION < 900014 will always be false. Please, don't add more checks on >>> unsupported versions. >> >> The fact that 8.X had reached its EOL merely means we cannot promise that >> things won't break. It does not mean we should immediately pull the plug >> and remove two lines from the Makefile, leaving 8.4 users with a broken >> port. >> >> It's up to maintainers to decide whether it's worth supporting some old >> FreeBSD version. Keeping around intricate patches and having to rebase >> and test on every update is a nuisance, so those patches probably deserve >> to rest in attic now. Two lines in the Makefile are hardly a burden. >> >> I typically would try to support as many FreeBSD versions as long the >> port stays manageable. Often it's not a problem, and is very polite to >> our users that do not want to upgrade for some reason (e.g. me and my >> laptop are happy with stable/8 and see no reason to update, as it will >> likely pessimize work experience without bringing any benefits over 8.4). >> >> That said, OSVERSION < 900014 will not always be false. And why do you >> want to be rude to our users and deliberately break things just because >> we no longer promise that they will work? >> > > Even in that case, this is wrong anyway as you enforce GCC while should should > require a modern compiler via compiler.mk. 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. so that policy is: 1) contrary to what the rest of the devs are doing 2) ineffective (due to 1) EOL means EOL. John