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. DavidReceived on Mon Jan 07 2013 - 08:39:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC