Generate snapshot_blob_host.bin for the host toolset.

The file snapshot_blob_host.bin was supposed to be generated when building the host toolset. However, the file snapshot_blob.bin was being generated instead, under every set of conditions.

Because of this, every time we build the host toolset, snapshot_blob_host.bin is not found. This causes the target (v8_external_snapshot) that generates such file to be run. This target generates snapshot_blob.bin instead of snapshot_blob_host.bin. This in turn causes all the targets that depend on snapshot_blob.bin to run again.

After this, we still don't have snapshot_blob_host.bin. So the next time we build, the whole process described above happens again.

BUG=421063

[baixo1, 2014-11-20 19:29:48]

baixo@google.com changed reviewers:
+ andrewhayden@google.com, rmcilroy@chromium.org, vogelheim@chromium.org

[baixo1, 2014-11-20 19:32:44]

baixo@google.com changed reviewers:
+ baixo@google.com

[baixo1, 2014-11-20 19:32:44]

Andrew, thanks for reporting this!

I know the solution is not ideal but I tried everything under the sun to simply
replace the last argument of 'action' by a variable that would be either
snapshot_blob.bin or snapshot_blob_host.bin, depending on what toolset it being
built. Nothing worked, so I took this path, unfortunately.

[Andrew Hayden (chromium.org), 2014-11-21 12:34:01]

andrewhayden@chromium.org changed reviewers:
+ andrewhayden@chromium.org

[Andrew Hayden (chromium.org), 2014-11-21 12:34:02]

I'm not too worried about the approach; it's not pretty, but GYP is obtuse with
things like this. More reasons to get the GN migration done, IMO, not that this
should be an excuse for poor code quality.

Anyhow: Two thoughts.
1. It would be nice to have a comment in each of your condition blocks that
succinctly tells the reader that the only difference is the addition of the
random-seed args. That way you don't have to sit there and carefully scrutinize
every option to see if they're really the same.

2. You might conceivably shrink the redundant bits a little by setting up
variables to hold the common args (as a list variable). You should be able to
use a list inside a list, so the args to the action should be theoretically able
to handle a variable (boilerplate_args or something) as well as your custom
random-seed arg.

#1 won't be necessary if you do #2. But I can live with #1, and it's probably
faster.

[rmcilroy, 2014-11-21 13:40:51]

On 2014/11/21 12:34:02, Andrew Hayden wrote:
> I'm not too worried about the approach; it's not pretty, but GYP is obtuse
with
> things like this. More reasons to get the GN migration done, IMO, not that
this
> should be an excuse for poor code quality.
> 
> Anyhow: Two thoughts.
> 1. It would be nice to have a comment in each of your condition blocks that
> succinctly tells the reader that the only difference is the addition of the
> random-seed args. That way you don't have to sit there and carefully
scrutinize
> every option to see if they're really the same.
> 
> 2. You might conceivably shrink the redundant bits a little by setting up
> variables to hold the common args (as a list variable). You should be able to
> use a list inside a list, so the args to the action should be theoretically
able
> to handle a variable (boilerplate_args or something) as well as your custom
> random-seed arg.
> 
> #1 won't be necessary if you do #2. But I can live with #1, and it's probably
> faster.

As discussed offline, it would be better if you could avoid having to redefine
the variables, and only redefine the 'action' in each of the condition /
target_condition blocks.  This may not be possible, but what should be possible
is to simply reuse the same code as was there before in each of the blocks
rather than splitting out the v8_random_seed into two different action blocks.

[baixo1, 2014-11-21 20:36:08]

On 2014/11/21 13:40:51, rmcilroy wrote:
> On 2014/11/21 12:34:02, Andrew Hayden wrote:
> > I'm not too worried about the approach; it's not pretty, but GYP is obtuse
> with
> > things like this. More reasons to get the GN migration done, IMO, not that
> this
> > should be an excuse for poor code quality.
> > 
> > Anyhow: Two thoughts.
> > 1. It would be nice to have a comment in each of your condition blocks that
> > succinctly tells the reader that the only difference is the addition of the
> > random-seed args. That way you don't have to sit there and carefully
> scrutinize
> > every option to see if they're really the same.
> > 
> > 2. You might conceivably shrink the redundant bits a little by setting up
> > variables to hold the common args (as a list variable). You should be able
to
> > use a list inside a list, so the args to the action should be theoretically
> able
> > to handle a variable (boilerplate_args or something) as well as your custom
> > random-seed arg.
> > 
> > #1 won't be necessary if you do #2. But I can live with #1, and it's
probably
> > faster.
> 
> As discussed offline, it would be better if you could avoid having to redefine
> the variables, and only redefine the 'action' in each of the condition /
> target_condition blocks.  This may not be possible, but what should be
possible
> is to simply reuse the same code as was there before in each of the blocks
> rather than splitting out the v8_random_seed into two different action blocks.

Ross: does it look better now? :)

Andrew: because this version is much more compact I judged the comments
would be "overkill". If you disagree I'll add them :). Thanks!

[rmcilroy, 2014-11-24 09:42:20]

On 2014/11/21 20:36:08, baixo1 wrote:
> On 2014/11/21 13:40:51, rmcilroy wrote:
> > On 2014/11/21 12:34:02, Andrew Hayden wrote:
> > > I'm not too worried about the approach; it's not pretty, but GYP is obtuse
> > with
> > > things like this. More reasons to get the GN migration done, IMO, not that
> > this
> > > should be an excuse for poor code quality.
> > > 
> > > Anyhow: Two thoughts.
> > > 1. It would be nice to have a comment in each of your condition blocks
that
> > > succinctly tells the reader that the only difference is the addition of
the
> > > random-seed args. That way you don't have to sit there and carefully
> > scrutinize
> > > every option to see if they're really the same.
> > > 
> > > 2. You might conceivably shrink the redundant bits a little by setting up
> > > variables to hold the common args (as a list variable). You should be able
> to
> > > use a list inside a list, so the args to the action should be
theoretically
> > able
> > > to handle a variable (boilerplate_args or something) as well as your
custom
> > > random-seed arg.
> > > 
> > > #1 won't be necessary if you do #2. But I can live with #1, and it's
> probably
> > > faster.
> > 
> > As discussed offline, it would be better if you could avoid having to
redefine
> > the variables, and only redefine the 'action' in each of the condition /
> > target_condition blocks.  This may not be possible, but what should be
> possible
> > is to simply reuse the same code as was there before in each of the blocks
> > rather than splitting out the v8_random_seed into two different action
blocks.
> 
> Ross: does it look better now? :)

Looks much better to me know, thanks.  lgtm

[baixo1, 2014-11-24 12:15:42]

The CQ bit was checked by baixo@google.com

[commit-bot: I haz the power, 2014-11-24 12:16:12]

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

[commit-bot: I haz the power, 2014-11-24 12:43:32]

Committed patchset #2 (id:20001)