Initial checkin of chromecast content embedder (cast_shell) and related build scripts.

chromecast/build/README

+This directory contains the scripts for setting up the environment and
+building Chromecast's content embedder, aka cast_shell. Currently we
+only support building on x86 Linux host (but targets can be x86 or arm).
+
+Prerequisites:
+--------------
+
+Besides the prerequisites for building Chromium (see
+https://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites),
+you need to have depot_tools in your path as we use ninja to build.
+
+Build:
+------
+
+To build cast_shell on x86 Linux,
+
+1. Set up the environment
+
+   $ source chromecast/build/chromecast_build_env.sh
+
+2. Pick the compielr and build flavor

[jam, 2014/04/04 01:01:24]

nit: spelling

+
+   Use Clang
+
+   $ setup_chromium_env_clang_chromecast `pwd -P` <Debug|Release>
+
+   Use GCC
+
+   $ setup_chromium_env_x86_chromecast `pwd -P` <Debug|Release>

[jam, 2014/04/04 01:01:24]

hmm, so in general, most devs are used to putting gyp variables in
chromium.gyp_env so that they persist. why is there a wrapper here, instead of
having a line showing which variable to put in that file? and extra points for
having one variable which the build system keys off, i.e. chromecast=1. this is
how the linux_chromeos config works

[lcwu1, 2014/04/05 01:17:13]

Having a wrapper to populate GYP_DEFINES is easier for our internal build
servers to build the whole device firmware (which Chromium is part of), but we
will look into chromium.gyp_env. (We might still need to keep the wrappers but,
if that's the case, will update the document on how to use chromium.gyp_env for
building chromecast.)

We would certainly love to only set one gyp variable and then, in common.gypi,
set all the other gyp variables needed for building chromecast, if that's
preferred.

+
+3. Create/update build files from gyp
+
+   $ update_gyp

[jam, 2014/04/04 01:01:24]

Why isn't this just build/gyp_chromium? I see the method also fetches gn, but I
thought gclient does that automatically when syncing?

[lcwu1, 2014/04/05 01:17:13]

Yes, gclient would pull in gn. However, in our current source management and
build system, we don't use gclient. (We use repo as we have other components
other than Chromium.) So we would still need the wrapper for our internal build
system. But for users who use gclient to pull in and sync their source tree,
they could certainly use gyp_chromium. I will update the document.

+
+4. Buidl

[jam, 2014/04/04 01:01:24]

nit: spelling

+
+   $ mymake cast_shell

[jam, 2014/04/04 01:01:24]

like above, why is there a wrapper around calling ninja?

it's good to have the developer process be the same across all of our configs.
since the intent is to make this a supported config on the trybots/CQ/buildbot,
we should make it as close to our existing configs as possible. that reduces the
friction when a win/mac/linux developer fetches this code to fix a bug in a
broken test etc

[lcwu1, 2014/04/05 01:17:13]

Yes, good point. Will do.