Start massaging the GYP files for building with clang on Windows

Start massaging the GYP files for building with clang on Windows

BUG=82385
TBR=cpu

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=246874

[hans, 2014-01-24 00:32:34]

I'd like to start doing this flag massaging in-tree. What do you think?

With this patch (and https://codereview.chromium.org/145593003/ for V8), I can
build url_unittests and net_unittests with a bleeding-edge clang-cl. I think
that's pretty cool :)

[Reid Kleckner, 2014-01-24 00:38:32]

Awesome!

https://codereview.chromium.org/146043003/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/146043003/diff/1/build/common.gypi#newcode4682
build/common.gypi:4682: # TODO(hans): Make this list shorter eventually.
Why turn these off if we've turned off -WX / -Werror?  Are these just the
noisiest?  I noticed -Wmsvc-include is far too noisy due to
http://llvm.org/PR18481, but the rest are probably true positives.

[Nico, 2014-01-24 00:39:34]

Hooray!

Add a comment somewhere in build/common.gypi with a link to the bug explaining
that this is all WIP (either where clang% is defined, or close to the largest
flag block).

[hans, 2014-01-24 00:54:03]

> Add a comment somewhere in build/common.gypi with a link to 
> the bug explaining
> that this is all WIP (either where clang% is defined, or 
> close to the largest
> flag block).

Done. I put it on the large block, because that's where I expect the action to
be.

https://codereview.chromium.org/146043003/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/146043003/diff/1/build/common.gypi#newcode4682
build/common.gypi:4682: # TODO(hans): Make this list shorter eventually.
On 2014/01/24 00:38:33, Reid Kleckner wrote:
> Why turn these off if we've turned off -WX / -Werror?  Are these just the
> noisiest?  I noticed -Wmsvc-include is far too noisy due to
> http://llvm.org/PR18481, but the rest are probably true positives.

It gets really noisy if I leave them on. I considered -Wno-everything, but I
figured that tracking and addressing these explicitly would be nice.

A lot of the noise is coming from third-party code that's inconvenient to
change, so the flags should move to the respective GYP-files for those
sub-projects, but I consider that part of the TODO here.

[Nico, 2014-01-24 01:11:28]

lgtm

https://codereview.chromium.org/146043003/diff/60001/third_party/libxml/libxm...
File third_party/libxml/libxml.gyp (right):

https://codereview.chromium.org/146043003/diff/60001/third_party/libxml/libxm...
third_party/libxml/libxml.gyp:259: '/U__STDC_VERSION__',
(why isn't this needed for cl.exe? I guess it doesn't define __STDC_VERSION__?
should clang-cl then?)

[Nico, 2014-01-24 01:11:56]

On 2014/01/24 00:32:34, hans wrote:
> I'd like to start doing this flag massaging in-tree. What do you think?
> 
> With this patch (and https://codereview.chromium.org/145593003/ for V8), I can
> build url_unittests and net_unittests with a bleeding-edge clang-cl. I think
> that's pretty cool :)

With what fallback percentage btw? 0, I guess?

[hans, 2014-01-24 01:22:10]

On 2014/01/24 01:11:28, Nico wrote:
>
https://codereview.chromium.org/146043003/diff/60001/third_party/libxml/libxm...
> third_party/libxml/libxml.gyp:259: '/U__STDC_VERSION__',
> (why isn't this needed for cl.exe? I guess it doesn't define __STDC_VERSION__?
> should clang-cl then?)

Exactly, cl.exe doesn't set __STDC_VERSION__ (at least not VS 2012 which I was
using) because it doesn't claim to support C99.

The problem is that Clang does support C99, and we do want to compile code that
takes advantage of that (ffmpeg), but we're also constrained by what the MSVC
library provides. I don't think it'll be a big problem in practice, and it might
work itself out if we migrate to VS 2013 which should have more C99 stuff in its
library.

> With what fallback percentage btw? 0, I guess?

Heh, no :)

We fall back when building ICU ("cannot mangle RTTI descriptors"), and a handful
of other files. I don't have a nice way of measuring the fallback-percentage
yet, but fallback only happened for a small minority.

[commit-bot: I haz the power, 2014-01-24 01:23:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hans@chromium.org/146043003/60001

[commit-bot: I haz the power, 2014-01-24 01:46:08]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[commit-bot: I haz the power, 2014-01-24 01:49:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hans@chromium.org/146043003/60001

[commit-bot: I haz the power, 2014-01-24 13:26:36]

Change committed as 246874

[Nico, 2014-08-03 22:11:14]

On 2014/01/24 01:22:10, hans wrote:
> On 2014/01/24 01:11:28, Nico wrote:
> >
>
https://codereview.chromium.org/146043003/diff/60001/third_party/libxml/libxm...
> > third_party/libxml/libxml.gyp:259: '/U__STDC_VERSION__',
> > (why isn't this needed for cl.exe? I guess it doesn't define
__STDC_VERSION__?
> > should clang-cl then?)
> 
> Exactly, cl.exe doesn't set __STDC_VERSION__ (at least not VS 2012 which I was
> using) because it doesn't claim to support C99.
> 
> The problem is that Clang does support C99, and we do want to compile code
that
> takes advantage of that (ffmpeg), but we're also constrained by what the MSVC
> library provides. I don't think it'll be a big problem in practice, and it
might
> work itself out if we migrate to VS 2013 which should have more C99 stuff in
its
> library.

Now that we're on 2013, is the change in libxml.gyp still needed?

[hans, 2014-08-04 16:49:12]

On Sun, Aug 3, 2014 at 3:11 PM,  <thakis@chromium.org> wrote:
> On 2014/01/24 01:22:10, hans wrote:
>>
>> On 2014/01/24 01:11:28, Nico wrote:
>> >
>
>
>
https://codereview.chromium.org/146043003/diff/60001/third_party/libxml/libxm...
>>
>> > third_party/libxml/libxml.gyp:259: '/U__STDC_VERSION__',
>> > (why isn't this needed for cl.exe? I guess it doesn't define
>
> __STDC_VERSION__?
>>
>> > should clang-cl then?)
>
>
>> Exactly, cl.exe doesn't set __STDC_VERSION__ (at least not VS 2012 which I
>> was
>> using) because it doesn't claim to support C99.
>
>
>> The problem is that Clang does support C99, and we do want to compile code
>
> that
>>
>> takes advantage of that (ffmpeg), but we're also constrained by what the
>> MSVC
>> library provides. I don't think it'll be a big problem in practice, and it
>
> might
>>
>> work itself out if we migrate to VS 2013 which should have more C99 stuff
>> in
>
> its
>>
>> library.
>
>
> Now that we're on 2013, is the change in libxml.gyp still needed?
>
> https://codereview.chromium.org/146043003/

Nope. https://codereview.chromium.org/443453002/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.