In Xcode 5, strip is no longer in SYSTEM_DEVELOPER_BIN_DIR. It is only in
DT_TOOLCHAIN_DIR. I also checked Xcode 4.6.1 and found that DT_TOOLCHAIN_DIR
was also set there, and strip is in both SYSTEM_DEVELOPER_BIN_DIR and
DT_TOOLCHAIN_DIR in that version.
Environment variables as set when Xcode is installed at /Applications/Xcode.app:
SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
ult.xctoolchain
xcrun should be able to find strip without having to resort to manual
environment interpretation.
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/24352006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227787 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When the SDK is set to something that Xcode doesn't know about (such as 10.6),
xcrun doesn't work correctly.
mark@cougar bash$ xcrun strip
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: no files specified
mark@cougar bash$ SDKROOT=/SDKs/MacOSX10.6.sdk xcrun strip
xcodebuild: error: SDK "/SDKs/MacOSX10.6.sdk" cannot be located.
xcrun: error: unable to find utility "strip", not a developer tool or in PATH
> Run strip via xcrun.
>
> In Xcode 5, strip is no longer in SYSTEM_DEVELOPER_BIN_DIR. It is only in
> DT_TOOLCHAIN_DIR. I also checked Xcode 4.6.1 and found that DT_TOOLCHAIN_DIR
> was also set there, and strip is in both SYSTEM_DEVELOPER_BIN_DIR and
> DT_TOOLCHAIN_DIR in that version.
>
> Environment variables as set when Xcode is installed at /Applications/Xcode.app:
>
> SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
> DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
> ult.xctoolchain
>
> xcrun should be able to find strip without having to resort to manual
> environment interpretation.
>
> R=thakis@chromium.org
>
> Review URL: https://codereview.chromium.org/24352006TBR=mark@chromium.org
Review URL: https://codereview.chromium.org/26235007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227524 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In Xcode 5, strip is no longer in SYSTEM_DEVELOPER_BIN_DIR. It is only in
DT_TOOLCHAIN_DIR. I also checked Xcode 4.6.1 and found that DT_TOOLCHAIN_DIR
was also set there, and strip is in both SYSTEM_DEVELOPER_BIN_DIR and
DT_TOOLCHAIN_DIR in that version.
Environment variables as set when Xcode is installed at /Applications/Xcode.app:
SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
ult.xctoolchain
xcrun should be able to find strip without having to resort to manual
environment interpretation.
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/24352006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227347 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
There's some data indicating that adbd on the device sometimes
spontaneously restores its connection.
After running a test, let's kill adbd and forwarder and wait for bit.
Reverts crrev.com/227038: this is not helping.
BUG=
NOTRY=True
Review URL: https://codereview.chromium.org/26186003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227278 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Although sharing the SDK with the one downloaded into
src/third_party/android_tools allowed us to avoid having to keep another
660MB SDK around, there were several downsides:
o It downloaded ARMv7 and x86 system images into the git repository in
src/third_party/android_tools, potentially confusing users who did
not have the new directories in their .gitignore.
o Messages in avd.py and usage of the emulator could lead users to
update the SDK checked into android_tools/, causing build problems
and a lot of confusion.
o The ARMv7 and x86 system images could end up being out of sync with
the SDK in android_tools/.
o The SDK in android_tools/ might be older than the one we used to
download separately.
The new solution is to revert large parts of r222121 and r223003 but not
completely: instead of downloading the SDK into a directory that is two
levels above the top-level src/ (there is no guarantee it is writable,
for example), the emulator SDK is now downloaded into
src/android_emulator_sdk/, which has also been added to .gitignore to
avoid confusion. Additionally, we build upon r222612 and install a newer
version of the SDK that works with version 18 of the Android API.
R=peter@chromium.org,navabi@chromium.org,bulach@chromium.org
BUG=304129
Review URL: https://codereview.chromium.org/25675010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227121 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The GpsLocationProvider is not actually used anywhere, and has most likely bit
rotted after years of no maintenance. It is brittle code written for a
specific version (3.1) of gpsd that is now outdated.
The only Chrome version that had this feature enabled (ChromeOS) makes no use
of it as no hardware was ever shipped that used GPS.
TBR=jam,brettw
Review URL: https://codereview.chromium.org/25752005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227104 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
There's some data indicating that adbd on the device sometimes
spontaneously restores its connection.
After running a test, let's kill adbd and forwarder and wait for bit.
This is a speculative change to try to make the bots healthier.
Relands crrev.com/226762: will also kill the forwarder.
BUG=
Review URL: https://codereview.chromium.org/25982005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227038 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 make matters worse on sharded bots. Possibly because
killing adbd on one device affects the host's adb connection with other devices.
> Android perf tests: kill adbd on the device after running a test.
>
> There's some data indicating that adbd on the device sometimes
> spontaneously restores its connection.
> After running a test, let's kill adbd and wait for bit.
>
> This is a speculative change to try to make the bots healthier.
>
> BUG=
>
> Review URL: https://codereview.chromium.org/25574002TBR=bulach@chromium.org
Review URL: https://codereview.chromium.org/25727009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@226980 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
dpranke@chromium.org
skyostil@google.com
schenney@chromium.org
craigdh@chromium.org
mark@chromium.org
scottmg@chromium.org
jww@chromium.org
xhwang@chromium.org
frankf@chromium.org
digit@chromium.org
bengr@chromium.org
phajdan.jr@chromium.org
zmo@chromium.org
shashishekhar@chromium.org
bulach@chromium.org
rmcilroy@chromium.org
thakis@chromium.org
erg@chromium.org
gab@chromium.org
tonyg@chromium.org
raphael.kubo.da.costa@intel.com
mvanouwerkerk@chromium.org
hclam@chromium.org
sivachandra@chromium.org
droger@chromium.org
jochen@chromium.org
jamesr@chromium.org
tapted@chromium.org
tbarzic@chromium.org
DHNishi@gmail.com