This CL introduces an automated and centralized way to embed
compatibility manifest into all *.exe files. With this CL,
a potential risk of behavioural inconsistency between
production binaries and unit test binaries is resolved by
enforcing the same compatibility context.
This CL uses 'target_conditions' feature of gyp to inject
manifest settings into each executable target. One tricky
part is that some executables such as setup.exe and
mini_installer.exe require external manifest file instead of
embedded one when component build is enabled.
See http://crbug.com/127233 for this.
You can override the gyp variable
'win_exe_compatibility_manifest' locally for a given
executable target to embed a custom compatibility manifest.
BUG=260692
Review URL: https://chromiumcodereview.appspot.com/19275010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@214427 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
So we can have the perf bots run with aura for a while. Depending how red
the waterfall we could leave it on for a long time.
This has happened before and it will happen again.
See for example r204698, r211007
BUG=259185
TEST=none
TBR=scottmg
Review URL: https://codereview.chromium.org/20929002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@214056 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This reverts r213418 as it caused Blink LayoutTest failures:
fast/js/kde/inbuilt_function_tostring.html
fast/workers/stress-js-execution.html
The crash in stress-js-execution looks particularly bad, as it
crashes with a CHECK failure about mismatched isolates (suggesting
that we're on the wrong thread).
BUG=v8:2745
TBR=jochen@chromium.org
Review URL: https://codereview.chromium.org/19476008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@213501 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Original CL here: https://codereview.chromium.org/17619005/
Changed since previous landing is diff between ps1 and ps2.
Diff since previous landing is a bit noisy, but in those files
against original is relatively small. The conditions for the
defines were incorrect and are simpler (and correct) now.
Previously:
Create top-level separate targets for browser and child dlls
The general idea is that there's top level targets chrome and chrome_child,
and corresponding content_app and content_app_child that depend on only
the subtargets that should be included in the appropriate dll.
Currently (probably) Windows-only and requires setting chrome_multiple_dll=1
for gyp.
Links, but Blink is still included in browser.
Single-process mode is currently disabled when chrome_multiple_dll is set.
Current graph is at:
http://commondatastorage.googleapis.com/chromelinkgraph/deps.html generated by
"python tools\win\split_link\graph_dependencies.py deps.html"
Remove the previous hacky-er attempt at this that was named "split dll".
TBR=jam@chromium.org
BUG=237249, 256965
Review URL: https://codereview.chromium.org/19572013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@212415 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Caused Linux x64 sizes to fail for reasons unclear.
> Create top-level separate targets for browser and child dlls
>
> The general idea is that there's top level targets chrome and chrome_child,
> and corresponding content_app and content_app_child that depend on only
> the subtargets that should be included in the appropriate dll.
>
> Pull bluetooth_utils from bluetooth_device into separate common target
> as it's referenced from chrome/common/extensions.
>
> Currently (probably) Windows-only and requires setting chrome_multiple_dll=1
> for gyp.
>
> Links, but Blink is still included in browser.
>
> Single-process mode is currently disabled when chrome_multiple_dll is set.
>
> Current graph is at: http://commondatastorage.googleapis.com/chromelinkgraph/deps.html
> generated by "python tools\win\split_link\graph_dependencies.py deps.html"
>
> Remove the previous hacky-er attempt at this that was named "split dll".
>
> TBR=jam@chromium.org
>
> BUG=237249,256965
>
> Review URL: https://codereview.chromium.org/17619005TBR=scottmg@chromium.org
Review URL: https://codereview.chromium.org/19572012
git-svn-id: http://src.chromium.org/svn/trunk/src/build@212239 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The general idea is that there's top level targets chrome and chrome_child,
and corresponding content_app and content_app_child that depend on only
the subtargets that should be included in the appropriate dll.
Pull bluetooth_utils from bluetooth_device into separate common target
as it's referenced from chrome/common/extensions.
Currently (probably) Windows-only and requires setting chrome_multiple_dll=1
for gyp.
Links, but Blink is still included in browser.
Single-process mode is currently disabled when chrome_multiple_dll is set.
Current graph is at: http://commondatastorage.googleapis.com/chromelinkgraph/deps.html
generated by "python tools\win\split_link\graph_dependencies.py deps.html"
Remove the previous hacky-er attempt at this that was named "split dll".
TBR=jam@chromium.org
BUG=237249,256965
Review URL: https://codereview.chromium.org/17619005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@212230 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
I'm guesing we haven't built this since rolling the NDK. I see errors of
the form:
In file included from ../../third_party/webrtc/modules/audio_coding/codecs/isac/fix/source/entropy_coding_neon.c:19:0:
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h: In function 'vshr_n_s32':
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h:3426:3: error: argument must be a constant
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h: In function 'vshl_n_s32':
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h:3798:3: error: argument must be a constant
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h: In function 'vshll_n_s16':
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h:4032:3: error: argument must be a constant
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h: In function 'vset_lane_s32':
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h:5082:3: error: argument must be a constant
third_party/android_tools/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/include/arm_neon.h:5082: confused by earlier errors, bailing out
One additional fix to md5sum is included.
NOTRY=true
Review URL: https://chromiumcodereview.appspot.com/18034029
git-svn-id: http://src.chromium.org/svn/trunk/src/build@211835 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Previously, any updates to scroll offset on the main thread updated both
scroll offset and layer position. CalcDrawProperties only used position
and ignored scroll offset. This patch changes that to consider scroll
offset equally with scroll delta when computing a layer's tranform.
Although this patch doesn't do anything about it yet, the end result of
this disentangling is that it will become possible to early out in
Layer::SetScrollOffset and not require a SetNeedsCommit when Blink
updates the scroll offset to the value that it already is on the
compositor thread.
This is step 3 of a patch series to disentangle layer position and
scroll offset. This patch depends on both
https://codereview.chromium.org/18405003/ and
https://codereview.chromium.org/18187004/.
R=danakj@chromium.org
BUG=256381
Review URL: https://chromiumcodereview.appspot.com/18400003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@211176 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
So we can have the perf bots run with aura for a while. Depending how red
the waterfall we could leave it on for a long time.
This has happened before and it will happen again.
See for example r204698
BUG=259185
TEST=none
TBR=scottmg
Review URL: https://codereview.chromium.org/18434006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@211007 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When doing a gyp_managed_install, we install APKs to the attached
device. Currently this can fail in many ways (no device attached,
multiple devices attached, device offline, device doesn't have root,
etc.). In addition, we need to detect changes to the attached device
(particularly when the device is switched, when an APK is
uninstalled/updated).
The current approach is to check all this information in the action
interacting with the device. This means that when there is some
problem we print the same warning messages for every APK that is built,
and, in some cases, multiple times for each APK. Also, we have to run
every install/push action every build because we detect changes to the
attached device in that action.
This change creates a new build action, "get device configurations".
This action inspects the attached devices, filters out offline devices,
filters out devices without root, and then writes a configuration
file with the id+metadata for the first non-filtered device. This
configuration is then used by each of the build steps that interacts
with the device. This consolidates all the device checking to a single
place, and the build actions don't need to do any checking. In
addition, to detect changes in the attached device, we only need to run
this single action every build and the install/push actions will only
change when the device/metadata changes.
Also, with this change we can now gracefully handle the case where
multiple devices are attached (currently just write the configuration
for the first valid device and install to that one).
Review URL: https://chromiumcodereview.appspot.com/16831013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@209582 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207516
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@208529 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This breaks the Android component build.
This reverts commit 125e64a9eb6406446fb864aea9fa887521f19616.
>> [Android] Support building standalone APK in component build
>>
>> Many people's workflows assume that they can install the APK created in
>> out/Debug/apks. With the component build that APK is actually an
>> "incomplete" APK that cannot be manually installed (or rather causes
>> obscure errors when manually installed).
>>
>> This change does two things. First, it moves the "incomplete" APK
>> output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
>> accidental installs of the "incomplete" APK. Second, it introduces an
>> option (create_standalone_apk) that when doing a component build, if
>> set, will merge the shared libraries into the "incomplete" APK to
>> create a standalone APK. This standalone APK will be created in
>> out/Debug/apks/.
>>
>> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
>>
>> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207516
BUG=
R=cjhopman@chromium.org
Review URL: https://codereview.chromium.org/17291013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207587 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207516 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207345 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adds a drop-down menu to the right of the search entry area on the OSX
app launcher. The menu is shown when clicked, and the button responds to
hover effects.
The menu button uses a new class, HoverImageMenuButton, which is derived
from an NSPopUpButton with minor extensions. Notably, it does not have a
dependency on browser themes, as does MenuButton from
chrome/browser/ui/cocoa. It tracks the mouse hover state and updates
the cell, which extends NSPopUpButtonCell and shows only the image in
the control frame -- no border, bezel, label, or dropdown arrow.
HoverImageMenuButtonCell supports a hover image, which behaves much like
an additional 'alternateImage' from NSButtonCell but for the hover
state, rather than the 'pressed' (or 'lit') state.
The menu shows the currently signed-in user, in a custom view as the
first item. It also (currently) shows menu options for Settings, Help, and
Feedback.
BUG=138633
TEST=Added app_list_unittests AppsSearchBoxMenuTest and
AppsSearchBoxMenuTest and tested manually to ensure the items are
launched correctly. Added ui_unittests HoverImageMenuButtonTest.*
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=206237
Review URL: https://chromiumcodereview.appspot.com/15955003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@206930 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Causes memory leaks in AppKit due to some obscure codepaths.
BUG=249630
> Menu for the OSX app launcher, HoverImageMenuButton in src/ui/base/cocoa/controls.
>
> Adds a drop-down menu to the right of the search entry area on the OSX
> app launcher. The menu is shown when clicked, and the button responds to
> hover effects.
>
> The menu button uses a new class, HoverImageMenuButton, which is derived
> from an NSPopUpButton with minor extensions. Notably, it does not have a
> dependency on browser themes, as does MenuButton from
> chrome/browser/ui/cocoa. It tracks the mouse hover state and updates
> the cell, which extends NSPopUpButtonCell and shows only the image in
> the control frame -- no border, bezel, label, or dropdown arrow.
>
> HoverImageMenuButtonCell supports a hover image, which behaves much like
> an additional 'alternateImage' from NSButtonCell but for the hover
> state, rather than the 'pressed' (or 'lit') state.
>
> The menu shows the currently signed-in user, in a custom view as the
> first item. It also (currently) shows menu options for Settings, Help, and
> Feedback.
>
> BUG=138633
> TEST=Added app_list_unittests AppsSearchBoxMenuTest and
> AppsSearchBoxMenuTest and tested manually to ensure the items are
> launched correctly. Added ui_unittests HoverImageMenuButtonTest.*
>
> Review URL: https://chromiumcodereview.appspot.com/15955003TBR=tapted@chromium.org
Review URL: https://codereview.chromium.org/17059002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@206375 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adds a drop-down menu to the right of the search entry area on the OSX
app launcher. The menu is shown when clicked, and the button responds to
hover effects.
The menu button uses a new class, HoverImageMenuButton, which is derived
from an NSPopUpButton with minor extensions. Notably, it does not have a
dependency on browser themes, as does MenuButton from
chrome/browser/ui/cocoa. It tracks the mouse hover state and updates
the cell, which extends NSPopUpButtonCell and shows only the image in
the control frame -- no border, bezel, label, or dropdown arrow.
HoverImageMenuButtonCell supports a hover image, which behaves much like
an additional 'alternateImage' from NSButtonCell but for the hover
state, rather than the 'pressed' (or 'lit') state.
The menu shows the currently signed-in user, in a custom view as the
first item. It also (currently) shows menu options for Settings, Help, and
Feedback.
BUG=138633
TEST=Added app_list_unittests AppsSearchBoxMenuTest and
AppsSearchBoxMenuTest and tested manually to ensure the items are
launched correctly. Added ui_unittests HoverImageMenuButtonTest.*
Review URL: https://chromiumcodereview.appspot.com/15955003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@206237 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We don't have any jarjar rules yet, but add the empty file now in order
that the downstream build can enable jarjar. This way, when rules are
added later it will just work, instead of breaking the downstream build
temporarily.
Also, make sure that when a jarjar rule file is being used, it's
considered as an input to the JNI generator step, to make sure the JNI
header files get regenerated when the rules change.
BUG=
Review URL: https://chromiumcodereview.appspot.com/15888011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@203141 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adds enable_pepper_cdms and ENABLE_PEPPER_CDMS to control building of this logic.
Previously, it was built for all platforms, but not all platforms use Pepper.
TEST=content_browsertests on platforms with and without Pepper CDM support
Review URL: https://chromiumcodereview.appspot.com/15028015
git-svn-id: http://src.chromium.org/svn/trunk/src/build@201738 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is part of the effort to bring TCMalloc to android.
The first goal is to get instrumentation to facilitate
integration with DMP and memory profiling.
This is not yet intended for full production usage as the
default allocator.
BUG=162208
Review URL: https://chromiumcodereview.appspot.com/14321006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@201524 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
thakis@chromium.org
Yukawa@chromium.org
fischman@chromium.org
jochen@chromium.org
cpu@chromium.org
adamk@chromium.org
hajimehoshi@chromium.org
joaodasilva@chromium.org
mostynb@opera.com
justincohen@google.com
scottmg@chromium.org
yfriedman@chromium.org
jam@chromium.org
enne@chromium.org
rmcilroy@chromium.org
droger@chromium.org
noamsml@chromium.org
derat@chromium.org
benm@chromium.org
mnaganov@chromium.org
shashishekhar@chromium.org
cjhopman@chromium.org
grunell@chromium.org
apatrick@chromium.org
dmikurube@chromium.org
lliabraa@chromium.org
dfalcantara@chromium.org
skyostil@google.com
chrisha@chromium.org
avi@chromium.org
cevans@chromium.org
tapted@chromium.org
apatrick@google.com
kbr@chromium.org
glider@chromium.org
jeanfrancoisg@chromium.org
earthdok@google.com
ilevy@chromium.org
groby@chromium.org
bshe@chromium.org
phajdan.jr@chromium.org
pan.deng@intel.com
torne@chromium.org
kjyoun@google.com
bengr@chromium.org
digit@chromium.org
qsr@chromium.org
ddorwin@chromium.org
aurimas@chromium.org
bulach@chromium.org