Date: Mon, 7 Jan 2013 09:39:34 +0000 From: David Chisnall <theraven@freebsd.org> To: Erik Cederstrand <erik@cederstrand.dk> Cc: Current FreeBSD <freebsd-current@freebsd.org>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, Ports FreeBSD <freebsd-ports@freebsd.org> Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! Message-ID: <410ACCF2-D1E6-45D9-AF93-B5625682644A@freebsd.org> In-Reply-To: <042CBED1-5257-4517-B040-9EE760BE7FE1@cederstrand.dk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?410ACCF2-D1E6-45D9-AF93-B5625682644A>