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

Mon Aug 25 21:14:34 PDT 2014

Hi James, I'll bite the bullet by trying to paraphrase Chandler. I think
that he was just trying to keep the discussion on topic. It happens quite
often that someone has additional questions, like you in this case. But as
Chandler pointed out, brokenness of platform headers on windows really
doesn't have anything to do with minimum version of msvc needed to compile
clang and that's what the discussion was all about.

Please start a new thread and people will be more than happy to answer your
questions. You can also try and search the archive for specific information
on how broken the headers are, but I don't think any sort of wrapping can
solve these issues, conforming compiler doesn't understand their dialect of
C++, it's that simple.

On Tue, Aug 26, 2014 at 1:10 PM, James Gregurich <bayoubengal at mac.com>
wrote:

>
> 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
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140826/535dda3d/attachment.html>