[cfe-dev] [PATCH] GCC Preprocessor Assertions revision 2

Chandler Carruth chandlerc at google.com
Tue Mar 6 10:58:50 PST 2012


On Tue, Mar 6, 2012 at 9:21 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com>wrote:

> So, to recap, the question is this, should we implement and maintain a gcc
> extension that was deprecated since gcc 3 ?


I think you've outlined well why we shouldn't. This is a high-cost addition
to Clang, and I completely agree with your assessment of that cost.

That leaves me with the question: why *should* we support this extension? I
see two possible reasons, but perhaps others have better justifications.
Here are my two cents. =]

1) There is a large body of (likely legacy) proprietary code that uses this
feature, and a company is interested in having Clang support for that body
of code.

2) There are enough open-source codebases still using this feature that
largely open-source-based code eco-systems are likely to have this missing
feature as a barrier to entry.

To address these in reverse order, #2 I simply don't believe to be true. We
have built a substantial amount of open source code with Clang and have not
once run into this. I'm confident that it will remain untrue as GCC has
also left this feature behind. I don't think there is any compelling reason
to believe this extension matters for adoption of Clang.


On the other hand, #1 is certainly plausible. That said, it is only a
*good* reason if the company with this large body of code is going to fund
long-term maintenance and improvements of Clang. I think it's risky to
accept such extensive changes until the long-term commitment has actually
materialized. I think a branch or something similar to reduce their merge
costs until we're satisfied there is a good maintenance story would be
better.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120306/b76a543b/attachment.html>


More information about the cfe-dev mailing list