Create new google_api/gcm directory, and add some of the initial base logic
for integrating protobufs with chrome sockets.
A SocketStream is an implementation of the ZeroCopyStream interfaces that allows
for asynchronously retrieving a message (with timeout support) which can then
be parsed by a CodedInputStream, or alternatively allows a CodedOutputStream
to write into a Chrome socket.
Once a SocketStream closes itself (which will happen on error or timeout), the
stream cannot be reused, and a new one should be created (typically with a
socket that has been reconnected). In general, the state of the socket stream
must be checked before interacting with it.
Also fixes issue in SocketTestUtil where mock Sockets aren't taking ownership
of IOBuffers that they're using (exposed by tests).
TBR=darin@chromium.org
BUG=284553
Review URL: https://codereview.chromium.org/23684017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@229533 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is my second attempt to do this, the first time https://codereview.chromium.org/23460023/ has been reverted (https://codereview.chromium.org/23858006) because the new target 'copy_syzyasan_binaries' was not build, so the SyzyASan binaries were missing from the syzygy dir...
Currently the syzygy_optimize script was taking care of copying asan_rtl.[dll|pdb] to the syzygy directory, this was causing 2 warnings when building a SyzyASan splitted build with ninja:
- ninja: warning: multiple rules generate syzygy\asan_rtl.dll. builds involving this target will not be correct; continuing anyway
- ninja: warning: multiple rules generate syzygy\asan_rtl.dll.pdb. builds involving this target will not be correct; continuing anyway
The multiple rules come from the fact that both syzygy\chrome.dll and syzygy\chrome_child.dll were trying to generate those artifacts.
I've also added agent_logger.exe to the syzygy directory, with this it'll be easier for the person grabing a SyzyASan build from the LKGR builder to use it.
I've also removed all the "--agent-dll" logic from syzygy_instrument.py as it was only copying the asan binaries to the syzygy directory, it's now done directly in the 'copy_syzyasan_binaries' gyp target.
R=chrisha@chromium.org
BUG=
Review URL: https://codereview.chromium.org/25890006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@229085 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Language detection is used from the renderer on most platform, but from the
browser on iOS. This CL moves it from chrome/common/ to a new "translate"
component, which allows to track and address more cleanly dependencies issues.
BUG=297777
Review URL: https://codereview.chromium.org/25531002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227015 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This seems to be preventing things landing through the CQ due to compile warnings on mac using clang, and on win-64.
Error such as
FAILED: ninja .. ..\..\media\cast\framer\cast_message_builder_unittest.cc ...
error C2220: warning treated as error - no 'object' file generated
warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
FAILED: clang++ ... -c ../../media/cast/audio_receiver/audio_receiver.cc -o obj/media/cast/audio_receiver/cast_audio_receiver.audio_receiver.o
In file included from ../../media/cast/audio_receiver/audio_receiver.cc:5:
../../media/cast/audio_receiver/audio_receiver.h:117:55:error: no newline at end of file [-Werror,-Wnewline-eof]
#endif // MEDIA_CAST_AUDIO_RECEIVER_AUDIO_RECEIVER_H_
> Build cast_unittest
>
> Build cast targets on all bots.
>
> R=justinlin@chromium.org
>
> Review URL: https://codereview.chromium.org/25891004TBR=hclam@chromium.org
Review URL: https://codereview.chromium.org/25368003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@226960 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
--
Use Finch to compare the performances of CLD1 and CLD2
Add a compile time constant CLD_VERSION, which indicates the version of CLD. If this is not define, Finch test to compare CLD1 and CLD2 is supposed to be used.
By this CL, each platform will have the below status:
Linux: Use both CLD1 and CLD2 (and use Finch).
Mac OS X: Use both CLD1 and CLD2 (and use Finch).
Windows: Use only CLD1 once because now CLD2 can't be compiled on Windows. After we can have CLD2 compiled on Windows, we will use CLD2 and Finch asap.
iOS: Still use only CLD1. (It's because it is hard to use both CLD1 and CLD2 on mobile platform because of the binary size impact.)
Android: Still use only CLD1. (The same reason as iOS)
So some platforms will have two CLD binaries, but this is temporal in the sense that we intend to use Finch only for Dev and Beta channel. Before releasing the stable Chromium version, we decide which version of CLD is adopted, make another CL to use only one CLD, and send a merge request. (Of course, we hope we will be able to adopt CLD2.)
BUG=240647
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=221380
Review URL: https://chromiumcodereview.appspot.com/22867032
git-svn-id: http://src.chromium.org/svn/trunk/src/build@221675 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add a compile time constant CLD_VERSION, which indicates the version of CLD. If this is not define, Finch test to compare CLD1 and CLD2 is supposed to be used.
By this CL, each platform will have the below status:
Linux: Use both CLD1 and CLD2 (and use Finch).
Mac OS X: Use both CLD1 and CLD2 (and use Finch).
Windows: Use only CLD1 once because now CLD2 can't be compiled on Windows. After we can have CLD2 compiled on Windows, we will use CLD2 and Finch asap.
iOS: Still use only CLD1. (It's because it is hard to use both CLD1 and CLD2 on mobile platform because of the binary size impact.)
Android: Still use only CLD1. (The same reason as iOS)
So some platforms will have two CLD binaries, but this is temporal in the sense that we intend to use Finch only for Dev and Beta channel. Before releasing the stable Chromium version, we decide which version of CLD is adopted, make another CL to use only one CLD, and send a merge request. (Of course, we hope we will be able to adopt CLD2.)
BUG=240647
Review URL: https://chromiumcodereview.appspot.com/22867032
git-svn-id: http://src.chromium.org/svn/trunk/src/build@221380 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
I recently switched the perf bots to use official builds on linux. However,
my first pass resulted in no breakpad syms.
In this change, making the perf bots build the linux_symbols
target so that breakpad symbols will be available to minidump_stackwalk when
a perf test crashes.
BUG=223572,271252
Review URL: https://chromiumcodereview.appspot.com/23060042
git-svn-id: http://src.chromium.org/svn/trunk/src/build@219611 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Allowing for:
1) Running gcapi_test on the try bots.
2) Being able to extract gcapi_dll from real official builds (instead of shipping local dev builds...)
2.5) (2) Since gcapi_dll depends on base and other targets, it's realllly bad to be shipping local dev builds from trunk; we should really always be looking to merge GCAPI changes at least up to beta and take the DLL from the official builders.
BUG=277657, 277064
Review URL: https://chromiumcodereview.appspot.com/23102010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@219090 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
jochen@chromium.org
pfeldman@chromium.org
zea@chromium.org
zmo@chromium.org
sebmarchand@chromium.org
ben@chromium.org
scottmg@chromium.org
tonyg@chromium.org
hclam@chromium.org
droger@chromium.org
tapted@chromium.org
engedy@chromium.org
acolwell@chromium.org
brettw@chromium.org
kkania@chromium.org
tfarina@chromium.org
phajdan.jr@chromium.org
finnur@chromium.org
darin@chromium.org
hajimehoshi@chromium.org
pneubeck@chromium.org
bdibello@google.com
gab@chromium.org
jschuh@chromium.org
simonjam@chromium.org
alokp@chromium.org
apatrick@chromium.org
blundell@chromium.org