Add yasm to the GN build

Add yasm to the GN build.

This is forked off of https://codereview.chromium.org/266613002 The code to compile yasm itself is mostly from that patch, with a few updates for the other changes.

Adds a template for running compiled binaries. Compared to Albert's patch above, this assumes the binary is generated by the source tree so can have a cleaner interface (just specify the label of the tool you use).

The yasm rule is new compared to Albert's patch. It uses a special wrapper script instead of the new compiled_action templates so it can properly support depfiles. This also adds convenient support for defines and include dirs.

This adds some trivial ios changes to the content/public/browser. This should be a NOP now.

Fixes a bug in GN depfile creation. Previously, the .d file was emitted as an output of the script, but this confuses ninja. This change just removes that.

BUG=
R=ajwong@chromium.org

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

[awong, 2014-06-11 20:34:03]

2 small nits

https://codereview.chromium.org/321323004/diff/20001/build/compiled_action.gni
File build/compiled_action.gni (right):

https://codereview.chromium.org/321323004/diff/20001/build/compiled_action.gn...
build/compiled_action.gni:63: # need a target build of your too, just leave off
the if statement.
But if you need a target build of your too, just leave off ->

If you need a target build of your tool as well, just leave out

https://codereview.chromium.org/321323004/diff/20001/third_party/yasm/run_yas...
File third_party/yasm/run_yasm.py (right):

https://codereview.chromium.org/321323004/diff/20001/third_party/yasm/run_yas...
third_party/yasm/run_yasm.py:33: # Assemble.
nit: assemble after generating the deps file maybe?  Feels weird to have the
deps have a newer timestamp than the assembled file.

[brettw, 2014-06-11 20:45:08]

https://codereview.chromium.org/321323004/diff/20001/third_party/yasm/run_yas...
File third_party/yasm/run_yasm.py (right):

https://codereview.chromium.org/321323004/diff/20001/third_party/yasm/run_yas...
third_party/yasm/run_yasm.py:33: # Assemble.
On 2014/06/11 20:34:03, awong wrote:
> nit: assemble after generating the deps file maybe?  Feels weird to have the
> deps have a newer timestamp than the assembled file.

What would it be in GCC? My mental model is that these are computed at the same
time. Whether one is trivially ahead of the other seems irrelevant.

I did it this way for the error handling. yasm doesn't seem to output errors
when writing dependencies. If you have an error in the source code, I thought it
was weird (although not strictly wrong) to generate a new .d file but no output.

[awong, 2014-06-11 22:05:45]

On 2014/06/11 20:45:08, brettw wrote:
>
https://codereview.chromium.org/321323004/diff/20001/third_party/yasm/run_yas...
> File third_party/yasm/run_yasm.py (right):
> 
>
https://codereview.chromium.org/321323004/diff/20001/third_party/yasm/run_yas...
> third_party/yasm/run_yasm.py:33: # Assemble.
> On 2014/06/11 20:34:03, awong wrote:
> > nit: assemble after generating the deps file maybe?  Feels weird to have the
> > deps have a newer timestamp than the assembled file.
> 
> What would it be in GCC? My mental model is that these are computed at the
same
> time. Whether one is trivially ahead of the other seems irrelevant.
> 
> I did it this way for the error handling. yasm doesn't seem to output errors
> when writing dependencies. If you have an error in the source code, I thought
it
> was weird (although not strictly wrong) to generate a new .d file but no
output.

Ran

strace -ffe open gcc -c test.c

Shows test.d opened created before test.o.

This actually kinda makes sense. If you think of the build file as a dependency
of the object file, you want to generate it first. Otherwise, immediately after
your build, your object file is "out of date" with respect to its dependency
file.

[brettw, 2014-06-11 22:21:38]

I guess I can change this, but it make me nervous. If yasm outputs anything to
stdout in any error condition you could get a corrupt .d file and ninja will
report some strange errors.

[awong, 2014-06-11 22:22:43]

On 2014/06/11 22:21:38, brettw wrote:
> I guess I can change this, but it make me nervous. If yasm outputs anything to
> stdout in any error condition you could get a corrupt .d file and ninja will
> report some strange errors.

Reverse it if there's a problem?  Logically it doesn't make sense to me that
your build file is newer than your object file. If I saw that, I'd want to
regenerate my object file...

[brettw, 2014-06-11 22:36:25]

On 2014/06/11 22:22:43, awong wrote:
> On 2014/06/11 22:21:38, brettw wrote:
> > I guess I can change this, but it make me nervous. If yasm outputs anything
to
> > stdout in any error condition you could get a corrupt .d file and ninja will
> > report some strange errors.
> 
> Reverse it if there's a problem?

By adding --version to the yasm_flags I was able to generate a .d file with
invalid contents that prevents ninja from running. Re-running GN does not fix
it, you have to know to delete that file, or do a full clean build. This is a
contrived example, but I would like to know that yasm is getting good input
before we take its output and save it.

> Logically it doesn't make sense to me that
> your build file is newer than your object file. If I saw that, I'd want to
> regenerate my object file...

This is not a build file. It's a dep file. You read the dep file to see if the
target is out-of-date. The date of the depfile is irrelevant, you always need to
read it.

[awong, 2014-06-11 22:42:37]

Regarding doing deps for or second, you're right that the deps file timestamp is
irrelevant. In light of that, I think your original ordering makes the most
sense.

https://codereview.chromium.org/321323004/diff/20001/build/compiled_action.gni
File build/compiled_action.gni (right):

https://codereview.chromium.org/321323004/diff/20001/build/compiled_action.gn...
build/compiled_action.gni:63: # need a target build of your too, just leave off
the if statement.
On 2014/06/11 20:34:03, awong wrote:
> But if you need a target build of your too, just leave off ->
> 
> If you need a target build of your tool as well, just leave out

I don't think you quite fixed the sentence...

[brettw, 2014-06-12 18:06:56]

PTAL

[awong, 2014-06-12 18:42:10]

LGTM ship it.

[brettw, 2014-06-12 19:36:04]

Committed patchset #7 manually as r276772 (presubmit successful).