[cfe-dev] Raising LLVM minimum required, 'dumb question'

[James Gregurich]

On Aug 25, 2014, at 6:53 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Mon, Aug 25, 2014 at 4:33 PM, James Gregurich <bayoubengal at mac.com> wrote:
> On Aug 25, 2014, at 5:44 PM, Chandler Carruth <chandlerc at google.com> wrote:
> >
> > As was mentioned, this is *completely* off topic for the clang developers mailing list. Please discuss this somewhere else.
> 
> I don’t really get this.  So here you have people upset with a direction the project is taking….which IS “on topic.”
> 
> FWIW, I don't think many people are at all upset. I think there are a couple of people upset on a mailing list, but none of them are significant contributors, and the contributors are quite happy with the direction.

For me, I’m undecided. I’m trying to understand the issues involved so that I can have an informed opinion. For instance, when I see the boost fellow from a few weeks back complain that now he cannot trust clang to have a rational preprocessor under some circumstances, my gut reaction is that he has a legitimate gripe. That complicates his life as a client of clang. As a client of clang myself who advocates and pushes its use in my sphere, that matters to me. certainly, situations like that need to have a quality solution. 


You personally expend quite a lot of energy traveling to conferences playing cheerleader for clang to get folks like us interested in it. When those who do get interested in it kvetch a little...and the kvetch isn’t an irrational kvetch, perhaps you should spend some of that energy addressing their kvetches rather than just dismissing them with “you aren’t a contributor” and leave us with the impression that we don’t really matter. Take the time to explain the situation, the decision that was made and get your customers on board with it. Make sure we have the things we need from a compiler standpoint to work around the imperfections.


> You're assuming that your questions from the original email were highlighting the problem that Clang's Windows C++ compatibility is trying to solve. To repeat from the original email:
> 
> """
> How many actual known instances of alleged broken lines are there in the entire Microsoft API header stack?
> 
> If one had the dream of just fixing the headers, how big of a job would it actually be?
> """
> 
> This is (IMO) not the relevant question for how or why we should be compatible. It doesn't matter how many lines there are or how big of a job fixing them would or wouldn't be. What folks are working on is being compatible with *existing* code on the Windows platform. The goal expressly isn't to change that code or fix those headers. So it doesn't really matter how big of a job it is to fix the headers.


yes it does. Because if the problem is one or two header files that cascade across dozens or more files in win32, then perhaps what one should do is address those couple of files by providing a solution that wraps them and adapts their behavior by some means. However, if the referenced problems are scattered all over the place, then such an approach is not practical.


> Now, you could reasonably ask "why not try to fix the headers" and in fact that *did* come up when the project was first undertaken (many years ago) to start supporting Windows C++ code better. The simple answer was that in many cases the headers could not be changed. Additionally, in other cases the change wasn't always clearly a "fix" or not; it would be a matter that people disagree on with some preferring the code as-is. And that really wasn't an interesting debate to enter into because it is hard to argue that legacy code which works today should change to support some hypothetical future compiler.

If the details were debated and a decision made, then explain the details. It is also perfectly acceptable to say “we discussed this issue and decided XXXX. Please refer to the archives and read what was already said before discussing it all over again." I wasn’t there for the discussion, but I have been following this thread keenly to see where it was going. You’ll pardon me if I desired additional information and wasn’t satisfied with the spot at which it fizzled out.


> Now, what was off topic? The idea of going into some other operating system's header files and trying to make value judgements about what constitutes a "bad" line of code, 

I’m not interested in that mindset at all. The code that Microsoft wrote back then was for that day and age. We’ve what…20 years of experience to look back upon that those guys didn’t have. It is what it is and I have no interest in finding fault with it. The question for me is…WHAT doesn’t compile, WHY doesn’t it compile and HOW does one address the situation in the real-world today. 


> And of course *all* of this is incredibly far afield from the actual subject of the thread on which it came up: switching the minimum supported *host* compiler from MSVC 2012 to MSVC 2013! This has zero bearing on how compatible Clang is with extensions used in system header files when *it* is the host compiler on a particular platform.


I’ve give you that one. However, the conversation did drift where it drifted and did raise the questions (at least in my mind) that it raised. However, you’ve now told me what I needed to know….that adapting the headers was considered and rejected. I’ll dig into the archives for further info.

thanks for taking the time to create a thoughtful response.

-James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140825/0ee32ec7/attachment.html>