From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 09:39:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 070CE2B0; Mon, 7 Jan 2013 09:39:39 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id CC3E46AB; Mon, 7 Jan 2013 09:39:38 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r079dHSr037219 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 7 Jan 2013 09:39:35 GMT (envelope-from theraven@freebsd.org) Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> Date: Mon, 7 Jan 2013 09:39:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <410ACCF2-D1E6-45D9-AF93-B5625682644A@freebsd.org> References: <50E97457.7050809@zedat.fu-berlin.de> <34476030-BDBF-46C4-8E7D-60FDC53B076A@FreeBSD.org> <50E9B385.9060104@zedat.fu-berlin.de> <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> To: Erik Cederstrand X-Mailer: Apple Mail (2.1278) Cc: Current FreeBSD , "O. Hartmann" , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:39:39 -0000 On 6 Jan 2013, at 20:38, Erik Cederstrand wrote: > You can't seriously blame LLVM for making progress. If ports rely on a = specific version of LLVM, it would be far better to create devel/llvm31, = devel/llvm32 etc. Well, I can (and, even with my LLVM committer hat on, do) blame LLVM for = not having a sensible deprecation strategy. Breaking the ABI is = unavoidable in a C++ project (unless you invent an entire metalanguage = on top of C++, as Qt does) but breaking the API is a huge pain, when it = would be no more effort in most cases to stick on a deprecation = attribute telling people what they should be using instead. Having llvm31, llvm32, and so on ports is likely to be unavoidable, as = lots of external projects end up depending on older versions of LLVM. = It would be worth splitting out clang from these. A few = refactoring-type tools depend on old versions of clang, but most = commonly people will be using latest clang with latest LLVM, plus = something else with old LLVM. =20 David=