[cfe-dev] Target.cpp

[Daniel Dunbar]

On Wed, Sep 23, 2009 at 1:10 PM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> Hi Daniel,
>
> Thanks.
>
>> By the way, I still don't have all my local patches in for testing on
> Windows (there are basically 3, one to add count + not to
> test/Scripts, one to add my local search headers, and one to hack
> around stdint.h), but the current number of test failures is ~60,
> which isn't too bad. A lot of the remaining ones are STL iterator
> pickyness which should be easy to eliminate if someone sits down to
> work through them.

> I still have the local patches you gave me before, which I was using,
> somewhat successfully, though the three of use trying the tests saw some
> different results.  But that was a couple months ago, with me being pulled
> onto other projects and vacation, so I'll see about running them again, if I
> can figure out how I was running them before.

The way I am running them now is using the "clang-test" project in the
project files. That should be the "official" way for MSVC (from a
CMake build), and ideally will "just work" one day.

In fact, this is now working in buildbot too!
  http://google1.osuosl.org:8011/waterfall
The buildbot of course has a higher test failure count because it
doesn't get my local patches. The current count is 73 after the fixes
for count/not which just went in.

>  I'll start looking at those test failures, hoping it's not too far over my head.

I suspect a number of the issues are trivial things regarding to the
use of the debug STL library, which is much pickier on Windows. For
example, all the static analyzer tests were failing due to code like
'&*t.end()'. Then there is a group of tests that use /dev/null, I will
probably fix this in 'lit'. Finally there are issues with standard
include files not being usable. Those are the three major classes of
failures I am aware of.

>  I do look forward to
> having the full solution for running the tests.

>> Also, what happened with your patch to add MSVC search paths in a more
> principled fashion? In my fuzzy memory I thought it had gone in, but I
> didn't actually see it in the source.
> Regarding the include path patch, it was kind of a hack job, mainly to
> facilitate our development.  I think you or someone raised some objection
> about one part where when both vc80 and c90 are present (both the
> VS80COMNTOOLS and VS90COMNTOOLS environment variables are set) and I used
> the one Clang was built with.  I kind of left it at that.
>
> How do you think I should handle this case?  Just use whichever is the later
> VS release?

For now, anything is better than nothing. Using the version the tools
was built with would be a fine start I guess, and perhaps closer to
what the user would want.

> I've enclosed a refreshed patch, in case you want to see it again.  It still
> has some hard-coded paths like before, which is also why it's kind of
> hackish.

Unless someone objects, I think the MSVC parts are worth putting it.
I'm not sure about the Cygwin/MinGW changes, were these intentional?

 - Daniel

> On Wed, Sep 23, 2009 at 12:34 AM, Daniel Dunbar <daniel at zuster.org> wrote:
>>
>> Hi John,
>>
>> Thanks for the refactoring, it looks good to me, I applied as r82621.
>>
>> On Tue, Sep 22, 2009 at 11:21 PM, John Thompson
>> <john.thompson.jtsoftware at gmail.com> wrote:
>> > Hi Daniel,
>> > Sorry for the duplicate email, I keep forgetting to pay attention to the
>> > return address.
>> > I've redone the patch without the Triple changes.  The current triple
>> > mechanism seems a bit out-of-date, as the correct triple for 64-bit
>> > Windows
>> > appears to be "x86_64-pc-win32", but we can leave that for whoever owns
>> > it.
>>
>> Ok.
>>
>> > At some point, if Clang wants to be it's own environment on Windows,
>> > we'll
>> > probably have to revise this a bit to be able to do something other than
>> > default to Visual Studio for the "win32" OS-type, but this is probably
>> > good
>> > enough for now.
>>
>> Yeah, we will probably want to go a long time before we care about
>> this. Adoption means being compatible with the existing environment,
>> as painful as it may be.
>>
>> > Thanks for dealing with this for me.
>> >
>> > -John
>> >
>> > P.S.  I added an empty define for __declspec.  Is this all that's
>> > needed?
>>
>> Dunno...
>>
>> By the way, I still don't have all my local patches in for testing on
>> Windows (there are basically 3, one to add count + not to
>> test/Scripts, one to add my local search headers, and one to hack
>> around stdint.h), but the current number of test failures is ~60,
>> which isn't too bad. A lot of the remaining ones are STL iterator
>> pickyness which should be easy to eliminate if someone sits down to
>> work through them.
>>
>> Also, what happened with your patch to add MSVC search paths in a more
>> principled fashion? In my fuzzy memory I thought it had gone in, but I
>> didn't actually see it in the source.
>>
>>  - Daniel
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>