GN: VS project calls ninja for single file compiles as well

GN: VS project calls ninja for single file compiles as well

Previously, compiling a single file in the generated project
invoked the normal compiler in Visual Studio.
Now we call ninja instead, this way it will be compiled with the
same options as it would compile when building the whole project.

It's now also possible to properly compile a file when using a
cross-compiler.

R=brettw@chromium.org, tmoniuszko@opera.com
BUG=

Committed: https://crrev.com/3dbc813107233e1164c0290e9268eddd03fa55ca
Cr-Commit-Position: refs/heads/master@{#389443}

[Tomasz Moniuszko, 2016-03-31 09:17:39]

LGTM

[NGG, 2016-04-05 18:06:32]

@brettw: Could you please have a look at this CL?

[brettw, 2016-04-18 17:20:04]

Sorry for the delay!

There is a lot of code in visual_studio_writer.cc that rewrites compiler
options. I'm thinking of everything in the CompilerOptions struct and possibly
other stuff. Is this rewriting even necessary now? It seems that having Visual
Studio know about these flags is redundant and maybe we can remove a lot of
complexity.

[NGG, 2016-04-18 21:39:44]

On 2016/04/18 17:20:04, brettw wrote:
> Sorry for the delay!
> 
> There is a lot of code in visual_studio_writer.cc that rewrites compiler
> options. I'm thinking of everything in the CompilerOptions struct and possibly
> other stuff. Is this rewriting even necessary now? It seems that having Visual
> Studio know about these flags is redundant and maybe we can remove a lot of
> complexity.

Some of the compiler options (like include directories, preprocessor defines,
etc..) are required because IntelliSense, VisualAssist and otber plugins use
those. I think most of the flags would not be required though.
I will be able to try to remove those next week.
I think that should be in a separate CL.

[Tomasz Moniuszko, 2016-04-19 07:21:08]

On 2016/04/18 21:39:44, NGG wrote:
> On 2016/04/18 17:20:04, brettw wrote:
> > Sorry for the delay!
> > 
> > There is a lot of code in visual_studio_writer.cc that rewrites compiler
> > options. I'm thinking of everything in the CompilerOptions struct and
possibly
> > other stuff. Is this rewriting even necessary now? It seems that having
Visual
> > Studio know about these flags is redundant and maybe we can remove a lot of
> > complexity.
> 
> Some of the compiler options (like include directories, preprocessor defines,
> etc..) are required because IntelliSense, VisualAssist and otber plugins use
> those. I think most of the flags would not be required though.
> I will be able to try to remove those next week.
> I think that should be in a separate CL.

I think most of these options are required by IntelliSense Error Reporting to
work properly. It's the feature that allows marking compilation errors directly
in VS text editor, at the time of writing the code, without a need of running
compilation process. I guess only |optimization| and |runtime_library| may be
redundant now (when compilation of single file will be handled by ninja). Please
keep in mind this feature when removing any of compilation options.

[brettw, 2016-04-19 17:56:52]

I see, thanks for the clarification. LGTM

[NGG, 2016-04-19 18:30:31]

The CQ bit was checked by ngg@ngg.hu

[commit-bot: I haz the power, 2016-04-19 18:30:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1835943002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1835943002/1

[commit-bot: I haz the power, 2016-04-19 18:34:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-19 18:34:18]

Try jobs failed on following builders:
  ios_rel_device_gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_gn...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[NGG, 2016-04-25 10:04:56]

The CQ bit was checked by ngg@ngg.hu

[NGG, 2016-04-25 10:04:57]

The patchset sent to the CQ was uploaded after l-g-t-m from brettw@chromium.org,
tmoniuszko@opera.com
Link to the patchset: https://codereview.chromium.org/1835943002/#ps20001
(title: "rebase")

[commit-bot: I haz the power, 2016-04-25 10:05:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1835943002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1835943002/20001

[commit-bot: I haz the power, 2016-04-25 10:37:26]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-04-25 10:39:15]

Description was changed from

==========
GN: VS project calls ninja for single file compiles as well

Previously, compiling a single file in the generated project
invoked the normal compiler in Visual Studio.
Now we call ninja instead, this way it will be compiled with the
same options as it would compile when building the whole project.

It's now also possible to properly compile a file when using a
cross-compiler.

R=brettw@chromium.org, tmoniuszko@opera.com
BUG=
==========

to

==========
GN: VS project calls ninja for single file compiles as well

Previously, compiling a single file in the generated project
invoked the normal compiler in Visual Studio.
Now we call ninja instead, this way it will be compiled with the
same options as it would compile when building the whole project.

It's now also possible to properly compile a file when using a
cross-compiler.

R=brettw@chromium.org, tmoniuszko@opera.com
BUG=

Committed: https://crrev.com/3dbc813107233e1164c0290e9268eddd03fa55ca
Cr-Commit-Position: refs/heads/master@{#389443}
==========

[commit-bot: I haz the power, 2016-04-25 10:39:16]

Patchset 2 (id:??) landed as
https://crrev.com/3dbc813107233e1164c0290e9268eddd03fa55ca
Cr-Commit-Position: refs/heads/master@{#389443}