From owner-freebsd-arch@freebsd.org Tue Oct 10 23:53:01 2017 Return-Path: Delivered-To: freebsd-arch@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 785F9E40A69 for ; Tue, 10 Oct 2017 23:53:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 537B671A67; Tue, 10 Oct 2017 23:53:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 1AADA10A8BC; Tue, 10 Oct 2017 19:52:53 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Nathan Whitehorn Subject: Re: Making C++11 a hard requirement for FreeBSD Date: Tue, 10 Oct 2017 16:26:10 -0700 Message-ID: <1966623.eKrA7uLGIR@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> References: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 10 Oct 2017 19:52:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 23:53:01 -0000 On Tuesday, October 10, 2017 07:36:25 AM Nathan Whitehorn wrote: > I think we can fix the problem, which is severe, in a week if we can get > a commitment from core@ to allow at least one of the following things: > > 1. Package sets (potentially only very minimal ones) uploaded for tier-2 > systems from machines not controlled and hosted by portmaster, but > otherwise project-affiliated (like our PPC build systems). > 2. The "base" ports built as part of the release/snapshot process and > either included on the media (better) or, at the least, available on the > official package repositories. > 3. Allow inclusion of the compiler either in src or in another > project-hosted repository connected to src (I realize this isn't > external toolchain, but it does still allow us to remove GCC 4.2 without > making the system unusable) I would prefer 2) as I think that is most consistent with what other folks have been pushing towards. I would be fine if we just hosted them in repositories so that 'pkg install' worked out of the box. At least if we start building them and publishing the repositories I think it is much easier to do more testing of them. Eventually we may also want them on the install media along with the base system dists, but just having them regularly built and published would be a good first step. I would propose that we build the sysroot required using the foo-xtoolchain-gcc toolchains. We don't yet produce any install images for MIPS. If we did I would advocate that we start providing release snapshots built using mips-xtoolchain-gcc (make CROSS_TOOLCHAIN=blah) and use the base dist from those releases as the sysroot to also build the base/ packages and provide those in a repository. I think that same approach could be perhaps more readily adopted for powerpc. That is, cross-building releases using powerpc-xtoolchain-gcc and then using the resulting base dist as a sysroot to build the base/ packages and publishing both of those as our snapshots for current. I suspect our release generation bits don't yet understand CROSS_TOOLCHAIN and probably will need some changes to handle that. -- John Baldwin