Previously, only 32-bit Google Chrome Linux was being built with x87 floating point math, which led to bugs caused by 80-to-{32,64}-bit rounding errors that weren't caught on the main Chromium builders. UMA data tells us there are ~0 Google Chrome Linux users without SSE2, making a strong case to require SSE2 across the board and align the Google Chrome build closer to the Chromium build.
As for disable_sse2 option, it was added in r45777 but it's unclear if anyone is using it outside of some other GYP code that flips it to 1 for ARM and MIPS architectures. Instead replace the few instances that don't support SSE2 with specific checks for the target architecture and remove the option entirely.
BUG=348761
R=jamesr@chromium.org
TBR=cpu
Review URL: https://codereview.chromium.org/187423002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256366 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- Remove DCHECK in non-official-release build by default
- Gyp variable dcheck_always_on=1 (existing) forces to enable DCHECK
in release build
- Remove flag --enable-dcheck
Other effects/notes:
- Now allow "buildtype=Official dcheck_always_on=1" (which will
enable DCHECK in official build) combination.
- Gyp variable logging_like_official_build no longer has an effect
- Leave DCHECK_IS_ON() unchanged. May deal with it in a later change
if needed.
This won't affect bots which use dcheck_always_on=1.
BUG=350462
TEST=LoggingTest.Dcheck
R=thakis@chromium.org
TBR=darin,sehr (command line changes in components/nacl and mojo)
Review URL: https://codereview.chromium.org/189603007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255987 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
0. Roll icu to r249466 to copy Android-specific icudtl.dat
1. Turn it in build/common.gypi by default except for android webview build. Move it inside L2 var dict and pull it up to the top level var dict to make 'Google Chrome' build on Android happy.
2. Add an entry for icudtl.dat to chrome/chrome_android_paks.gypi so that
it's copied to assets directory for Chrome and related targets.
3. Extract icudtl.dat from the asset and copy to DIR_ANDROID_APP_DATA and make it world-readable so that child processes (sandboxed with uid) can read it.
4. Add icudtl.dat to MANDATORY_PAKS list in various Android build targets
Google Chrome has #4 but in a separate CL ( https://chrome-internal-review.googlesource.com/#/c/155554/ ). That CL will land before this CL.
This also depends on a Blink change https://codereview.chromium.org/183013006/TBR=avi@chromium.org
BUG=72633
TEST=base_unittests:*Convers*, net_unittests:*IDN*, browser tests on all platforms.
TEST=On Android, 1. Layout tests
2. build/android/test_runner.py gtest -s webkit_unit_tests
--gtest_filter=WebFrameTest.SelectRange*
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=253938
Review URL: https://codereview.chromium.org/156333002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255762 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This will be used in Blink to protect the old implementation of hiDPI
filter scaling. Once CC has been taught how to apply hiDPI to filters,
the Blink implementation will be switched off at the same time by
removing this #define.
BUG=281516
Review URL: https://codereview.chromium.org/182863007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255580 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
May have caused crashes on Android layout test bots.
> Enable icu_use_data_file_flag on Android
>
> 0. Roll icu to r249466 to copy Android-specific icudtl.dat
> 1. Turn it in build/common.gypi by default except for android webview build. Move it inside L2 var dict and pull it up to the top level var dict to make 'Google Chrome' build on Android happy.
> 2. Add an entry for icudtl.dat to chrome/chrome_android_paks.gypi so that
> it's copied to assets directory for Chrome and related targets.
> 3. Extract icudtl.dat from the asset and copy to DIR_ANDROID_APP_DATA and make it world-readable so that child processes (sandboxed with uid) can read it.
> 4. Add icudtl.dat to MANDATORY_PAKS list in various Android build targets
>
> Google Chrome has #4 but in a separate CL ( https://chrome-internal-review.googlesource.com/#/c/155554/ ). That CL will land before this CL.
>
> TBR=avi@chromium.org
> BUG=72633
> TEST=base_unittests:*Convers*, net_unittests:*IDN*, browser tests on all platforms.
>
> Review URL: https://codereview.chromium.org/156333002TBR=jshin@chromium.org
Review URL: https://codereview.chromium.org/183863005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@254020 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
0. Roll icu to r249466 to copy Android-specific icudtl.dat
1. Turn it in build/common.gypi by default except for android webview build. Move it inside L2 var dict and pull it up to the top level var dict to make 'Google Chrome' build on Android happy.
2. Add an entry for icudtl.dat to chrome/chrome_android_paks.gypi so that
it's copied to assets directory for Chrome and related targets.
3. Extract icudtl.dat from the asset and copy to DIR_ANDROID_APP_DATA and make it world-readable so that child processes (sandboxed with uid) can read it.
4. Add icudtl.dat to MANDATORY_PAKS list in various Android build targets
Google Chrome has #4 but in a separate CL ( https://chrome-internal-review.googlesource.com/#/c/155554/ ). That CL will land before this CL.
TBR=avi@chromium.org
BUG=72633
TEST=base_unittests:*Convers*, net_unittests:*IDN*, browser tests on all platforms.
Review URL: https://codereview.chromium.org/156333002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@253938 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is finally possible following the conjunction of scottmg's work on embedding manifests as resources post-link and mine/caitkp's work on the version assembly manifest and its compatibility with the component build installer :)!
BUG=276953, 346843, 127233
TEST=
A) Installer still works in component builds
B) Self-destruct now works in component builds
C) Incremental linking still works for chrome_dll/unit_tests/browser_tests.
R=robertshield@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/179903004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@253534 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When running Instruments, it is better to use a Release build, but
with a dSYM file. So introduce a new configuration 'Profile' based
on 'Release' that also generates a dSYM file.
This uses a separate configuration because Instruments needs a
real dSYM file, and generating it with dsymutil is slow. Moreover,
it is not possible to build a dSYM file from the Release build, and
profiling a Debug build is not really representative of real usage.
BUG=None
Review URL: https://codereview.chromium.org/179933002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@253444 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- Add ExternalVideoSurfaceContainer which handles the external surface for the hole punching in WebView.
- Refactor the callbacks of ContentViewClient on the hole-punching to make them have the single purpose per each function.
BUG=329447
Review URL: https://codereview.chromium.org/132233042
git-svn-id: http://src.chromium.org/svn/trunk/src/build@252571 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Most people don't use this parameter and get arm binaries. This is
still the default, so this change shouldn't affect most people.
Folks should instead pass -Dtarget_arch to gyp. (Or, soon, envsetup will stop
clobbering GYP_DEFINES, then you can just add target_arch to your GYP_DEFINES.)
Note that in gyp land, 'mips' is called 'mipsel' and 'x86' is called 'ia32'.
'arm' stays 'arm'.
So for example, instead of running
. build/android/envsetup.sh --target-arch=mips
android_gyp
you'd run
. build/android/envsetup.sh
android_gyp -Dtarget_arch=mipsel
I updated the bots I was able to find to pass the -D flag in addition to
--target-arch. After this CL here is in, I'll update the bots to stop passing
--target-arch, and then I'll make --target-arch a hard error in this script for
a while, to make sure nobody still uses it.
BUG=330631,34476
R=torne@chromium.org
TBR=yfriedman
Review URL: https://codereview.chromium.org/171903002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@252034 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
If ANDROID_SDK_ROOT is set, it's still added to the path for now, but it's
no longer passed to gyp. If you want to set a custom sdk root, call gyp like
"build/gyp_chromium -Dandroid_sdk_root=path".
If ANDROID_SDK_ROOT is not set, it's still getting exported with a default
value that's identical to the default value of gyp's android_sdk_root variable.
ANDROID_SDK_TOOLS and ANDROID_SDK_BUILD_TOOLS_VERSION are now
completely ignored. Set the android_sdk_tools or android_sdk_build_tools_version
gyp defines instead if you need to change either. If they are not set,
envsetup no longer sets them.
(Dependent on an internal that changes a bot to set these gyp defines in
addition to the env vars.)
BUG=330631
NOTRY=true
Review URL: https://codereview.chromium.org/164193010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@251904 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Right now when supplying a 32-bit sysroot via the 'sysroot' GYP flag on a 64-bit host arch,
pkg-config (and pkg-config-wrapper) fail to generate the correct 32-bit paths within that sysroot.
The solution is to chroot into that directory and run pkg-config from there.
This is intended to work with schroot scripts like 'precise32' generated when running build/install-chroot.sh
BUG=324207
R=piman@chromium.org
Review URL: https://codereview.chromium.org/163583003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@251353 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Clients should set the host_os gyp variable instead. (As far as I can tell,
this flag was added for the webview build, and this CL updates gyp_webview
to use the gyp define instead. I haven't found other clients.)
Since several gyp targets check the value of host_os in a
target_conditions block and most of the build/common.gypi variables
aren't available during target_conditions processing time, use the same
trick that chromium_code uses to make host_os available at target_conditions
time.
BUG=330631
NOTRY=true
Review URL: https://codereview.chromium.org/153623011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@251138 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Since iOS 7, the iPhone 5s, the iPad Air and the iPad Mini Retina
supports 64-bits binaries. This requires building a fat binary with
support for both armv7 and arm64 (and optionally armv7s).
In an effort to prepare building such a fat binary for Chrome on
iOS, introduce a "target_subarch" variable that control the variant
we want to build (32-bit only, 64-bit only -- mainly for debugging,
fat binary).
This require introducing way to use the clang compiler shipped with
Xcode, as the clang compiler shipped with Chromium code does not
support "arm64" architecture yet (Apple has not yet opensource the
implementation).
BUG=341453, 314720
R=mark@chromium.org
Review URL: https://codereview.chromium.org/156473005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@251083 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
1. Enabling icu_use_data_file_flag led to a crash because GetStringUTF8 (that relies on ICU to determine whether the current UI language is RTL) is called before InitializeICU is called. Instead of using GetStringUTF8, get the string directly from the resource bundle because there's no need to adjust the string for the RTL locale in this particular case.
2. update chromite to a revision that copies icudtl.dat when icu_use_data_file_flag is on.
The switch (icu_use_data_file) will be flipped in a follow-up CL (either in build/common.gypi or chromeos-chrome ebuild file or both as necessary).
BUG=72633
TEST=cros_{amd,x86,amd64} pass all the tests. No actual change with this CL.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=248325
Review URL: https://codereview.chromium.org/135963010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@248954 4ff67af0-8c30-449e-8e8b-ad334ec8d88c