This CL modifies remoting/tools/localize.py script such that it can:
- be invoked via 'pymod_do_main' filter.
- generate a separate output file for each locale/language.
- produce the list of output files for given set of parameters.
remoting.gyp now generates the lists of .pak and message.json files invoking the script via 'pymod_do_main' filter. 'pymod_do_main' is necessary to pass paths unaltered between GYP and python.
The script was also renamed to remoting/tools/build/remoting_localize.py to avoid potential name clashes since the script is globally visible now.
TBR is for the DEPS changes only.
TBR=cpu@chromium.org
BUG=155204
Review URL: https://chromiumcodereview.appspot.com/18868009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@211227 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
If a generator is set explicitly (via GYP_GENERATORS or via -f or via
chromium.gyp_env), it will have precedence over the new default.
If you've used make until now, run `ninja -C out/Debug` instead of `make` to
build.
If you're using goma, go/ma has documentation on how to use goma with ninja.
(It's the same as make, except that CC / CXX are now picked up at `gclient sync`
/ `gclient runhooks` / `build/gyp_chromium` time instead of at build time.)
If you can't use ninja for some reason, `export GYP_GENERATORS=make` and sync
again. Please also send me (thakis@chromium.org) an email explaining why ninja
does not work for you.
This will also switch all bots that don't explicitly set a build tool (including
the public bots). compile.py will use ninja instead or make based on if
build.ninja or Makefile are newer, so they should build the right thing
automatically. And since built products end up in the same place, packaging
should do the right thing too.
BUG=239257
R=mark@chromium.org
Review URL: https://codereview.chromium.org/15100009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@199603 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
It looks like this made win extract_build fail.
Adds the ability for devs/troopers/etc. to set 'landmines' in the tree so that
the build will selectively clobber when a builder moves over a revision with such
a change.
This cl has an basis landmines.py, and hooks the clobber mechanism to the android
build scripts.
The relevant cl which implements this for
compile.py is here: https://chromiumcodereview.appspot.com/11234013/
I'm planning to also implement an informational invocation for gclient to let devs know
about any potential landmines so they can decide if they need to clobber.
R=cmp,maruel@chromium.org
BUG=121897
Review URL: https://chromiumcodereview.appspot.com/11175016TBR=iannucci@chromium.org
Review URL: https://codereview.chromium.org/11293111
git-svn-id: http://src.chromium.org/svn/trunk/src/build@166105 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adds the ability for devs/troopers/etc. to set 'landmines' in the tree so that
the build will selectively clobber when a builder moves over a revision with such
a change.
This cl has an basis landmines.py, and hooks the clobber mechanism to the android
build scripts.
The relevant cl which implements this for
compile.py is here: https://chromiumcodereview.appspot.com/11234013/
I'm planning to also implement an informational invocation for gclient to let devs know
about any potential landmines so they can decide if they need to clobber.
R=cmp,maruel@chromium.org
BUG=121897
Review URL: https://chromiumcodereview.appspot.com/11175016
git-svn-id: http://src.chromium.org/svn/trunk/src/build@166085 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This target generates the locale .pak files on Windows. Since nothing
depends on this target, it doesn't build by default (they're not used
yet).
Specific changes:
- Have locale_settings_win.grd generate .pak files.
- Use pymod_do_main to avoid some shell escaping problems (and it's a bit
faster).
- Rewrite repack_locales.py to work with pymod_do_main.
BUG=92724
Review URL: http://codereview.chromium.org/7648001
git-svn-id: http://src.chromium.org/svn/trunk/src/build@97012 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
but currently only on the Mac.
These relationships should be errors on all platforms, but some currently
exist on non-Mac platforms. See http://crbug.com/35878. Because the Mac is
the only platform where a circular dependency between .gyp files is known to
cause tangible problems, the portions of Chromium's .gyp files that are used
by Macs have been fixed to remove these relationships, and the check is left
enabled on the Mac to ensure that no new ones are created.
BUG=35308
TEST=none
Review URL: http://codereview.chromium.org/600151
git-svn-id: http://src.chromium.org/svn/trunk/src/build@39128 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Why: Simpler build code. If everybody includes it, it should be included automatically.
Why now: The webkit chromium builds need it be specified, since can't default to build/common.gypi.
What was done:
1. build/common.gypi's contents were moved to a new file build/gyp_chromium.gypi
2. tools/gyp/gyp_chromium was moved to build/gyp_chromium and made to automatically include build/gyp_chromium.gypi.
3. lots of gyp files were fixed to not refer to build/common.gypi any more.
4. o3d which also builds independently of chrome, was fixed to have a gyp_o3d that includes gyp_chromium.gypi too.
5. build/common.gypi was left empty, because there are some external projects that still refer to it.
Things that are left to do after this patch is in:
1. The following external files (in other repositories) need to stop include common.gypi
./third_party/hunspell/hunspell.gyp
./third_party/icu/icu.gyp
./v8/tools/gyp/v8.gyp
2. Once nobody refers to common.gypi anymore, delete common.gypi
-or-
Delete gyp_chromium.gypi and move its content back to common.gypi
Tested on mac, win and linux. On win, got a few unit tests errors on chrome bookmarks, which should not be related. I'm running again with clobber to verify.
Review URL: http://codereview.chromium.org/206006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@26302 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
schenney@chromium.org
alexeypa@chromium.org
adamk@chromium.org
thakis@chromium.org
abarth@chromium.org
tony@chromium.org
phajdan.jr@chromium.org
iannucci@chromium.org
vandebo@chromium.org
grt@chromium.org
yongsheng.zhu@intel.com
bradnelson@google.com
joi@chromium.org
maruel@chromium.org
pam@chromium.org
thomasvl@chromium.org
evan@chromium.org
rsesek@chromium.org
mark@chromium.org
yaar@chromium.org
sgk@google.com
mattm@chromium.org