From owner-svn-ports-all@freebsd.org Mon Dec 30 03:52:39 2019 Return-Path: Delivered-To: svn-ports-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 24DA01D3C3B; Mon, 30 Dec 2019 03:52:39 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47mNmj17dpz4V4J; Mon, 30 Dec 2019 03:52:36 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id 722CC33E12; Sun, 29 Dec 2019 22:52:35 -0500 (EST) Received: from anthias (unknown [103.14.88.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hamza.pair.com (Postfix) with ESMTPSA id F178033E11; Sun, 29 Dec 2019 22:52:32 -0500 (EST) Date: Mon, 30 Dec 2019 13:52:26 +1000 (+10) From: Gerald Pfeifer To: Tobias Kortkamp cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r517725 - head/lang/gcc9 In-Reply-To: <20191222055804.GA251@urd.tobik.me> Message-ID: References: <201911160812.xAG8CZEi075212@repo.freebsd.org> <20191214155544.GA32673@urd.tobik.me> <20191222055804.GA251@urd.tobik.me> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 47mNmj17dpz4V4J X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gerald@pfeifer.com designates 209.68.5.143 as permitted sender) smtp.mailfrom=gerald@pfeifer.com X-Spamd-Result: default: False [3.71 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[220.88.14.103.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(0.00)[+a:hamza.pair.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[pfeifer.com]; TO_DN_SOME(0.00)[]; BAD_REP_POLICIES(0.10)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-2.09)[ip: (-7.35), ipnet: 209.68.0.0/18(-1.98), asn: 7859(-1.09), country: US(-0.05)]; NEURAL_SPAM_MEDIUM(0.27)[0.273,0]; NEURAL_SPAM_LONG(0.53)[0.527,0]; RCVD_IN_DNSWL_NONE(0.00)[143.5.68.209.list.dnswl.org : 127.0.10.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7859, ipnet:209.68.0.0/18, country:US]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[220.88.14.103.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 03:52:39 -0000 On Sun, 22 Dec 2019, Tobias Kortkamp wrote: >>> when can we enable PLUGINS by default? > It unlocks the ability to package GCC plugins (like the one in > security/afl++) without custom builds of GCC. I would like to > enable afl++'s GCC option by default, but a prerequisite of that > is that PLUGINS is turned on by default in lang/gcc9. > > Are there any downsides in enabling PLUGINS by default? One downside is that the GCC plugin APIs explicitly are not stable, so can (and will) change with new versions of GCC. Hence other ports using them will either need to pin to a fixed version of GCC (USE_GCC=9) and maybe become maintenance challenges that way or become a blocker when we are next looking into updating the default version of GCC in Mk/bsd.default-versions.mk. It's this kind of dependency that has made the later rather painful for the past years and iterations, though I do happily acknowledge that you have been very supportive and helpful there. Plus we have managed to fully catch up, for the first time in a long while. :-) So I have gone ahead and enabled plugins for lang/gcc10-devel and lang/gcc9-devel with recent snapshots and plan on letting lang/gcc9 follow at one point in January. Why a bit later? In my experience maintaining the lang/gcc* ports "you never know". ;-) Sometimes it's non-x86 architectures (notably powerpc has kept us somewhat busy this year), sometimes it's -CURRENT, sometimes simply broader usage, and letting things settle a few weeks via gcc9-devel has been proven useful. Makes sense? Gerald