On Jun 5, 2012, at 6:46 AM, Jonathan Schleifer <[email protected]> wrote:

> Am 19.05.2012 um 21:34 schrieb John McCall:
> 
>> I apologize that this means significantly more work for you;  it's always
>> awkward being the one forcing a generalization.
> 
> I'm not really deep enough into Clang to rewrite the whole way how clang 
> handles different runtimes and I actually think that asking me to rewrite all 
> that when I just wanted a single flag is a little bit too much, don't you 
> think? This is the first Clang patch that's more than a 1-liner I ever did 
> and it took me ages to get the options stuff working. Someone who actually is 
> familiar with the Clang code should be able to do this much faster with less 
> work.
> 
> Can't you just let me have this one single option and then later someone who 
> is familiar enough with Clang can rewrite the way Clang handles different 
> runtimes?

Agreeing to what you are asking for would be a terrible policy decision for the 
project. When the special cases add up, we have to generalize or the code base 
becomes unmaintainable. If you peruse the commit logs, you'll see this 
happening everywhere: developers generalize and refactor to make something 
beautiful, then slide their new feature into that framework. It's how the 
LLVM/Clang community continually improves the code base, and it is the reason 
that we're able to build as much as we have so quickly. 

Remember, adding a command-line option extends the user interface of Clang. We 
can't just take that command-line option back once we've added it. So, let's 
imagine that we take this one single option. Then, down the road, someone does 
the necessary generalization, and we have a new command-line option. 
Unfortunately, the old command-line option can never go away, because people 
depend on it, so we have to map old to new "forever". Now multiply this by 
everyone who wants just one single option/feature/etc., and you have a horrible 
mess down the road.

We're all reaping the benefits of us *not* allowing little exceptions like this 
in Clang. Let's keep doing things the right way when we know what that is.

        - Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to