For build_with_chromium==1 the includes will be the same.
For build_with_chromium==0 the <(DEPTH) variable is replaced by ../..
which should be the same in all common use cases.
This change makes the include paths for all GYP targets
more similar to the setup in the
direct_dependent_settings section further down.
BUG=4185
TESTED=Trybots + build in Chromium with third_party/webrtc patched with this CL.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41739004
Cr-Commit-Position: refs/heads/master@{#8219}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8219 4adac7df-926f-26a2-2b94-8c16560cd09d
The work landed in 4034 (use of HW AEC in AppRTC) is currently not
active by default since we build for Open SL. I missed that when I
did my initial change (since I always disabled OpenSL by GYP_DEFINES).
This CL ensures that Java based audio is used as default in WebRTC.
It would be great if we could shift over to Open SL (to cut latency)
but that would (today) mean that we can't support the HW AEC.
Hence, we are not ready to do so yet.
BUG=4034
R=kjellander@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36699004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8040 4adac7df-926f-26a2-2b94-8c16560cd09d
All *neon.S files in aecm and ns modules have been removed. We need no
assembly offset generation now.
Pass byte to byte conformance test for aecm and ns test in audioproc
between new NEON (written in intrinsics) version and C version on both
ARMv7 and ARM64.
BUG=3580
R=andrew@webrtc.org, jridges@masque.com
Change-Id: I05d43d0c04d00bead65ca8c8fda25f0a42394b2b
Review URL: https://webrtc-codereview.appspot.com/32229004
Patch from Zhongwei Yai <zhongwei.yao@arm.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7800 4adac7df-926f-26a2-2b94-8c16560cd09d
Allows successful build of arm64 libraries using
GYP_DEFINES="OS=ios target_arch=arm64 target_subarch=arm64".
Note that not all libraries will be NEON optimized (eg common_audio),
however most importantly libvpx will be. WEBRTC_ARCH_ARM needs to be
defined so that libvpx doesn't post-process, which is significantly
detrimental to performance.
BUG=3898
R=kjellander@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26959004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7573 4adac7df-926f-26a2-2b94-8c16560cd09d
Modifies the previous condition to additionally not use openmax_dl on
iOS. Remove the All target's direct dependency on it, as it is now
pulled in by the targets that need it.
Add gn support since an openmax_dl gn target is available.
BUG=chromium:415393, webrtc:3906
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23949004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7397 4adac7df-926f-26a2-2b94-8c16560cd09d
Targets must now link with implementation of their choice instead of at "gyp"-time.
Targets linking with libjingle_media:
- internal implementation when build_with_chromium=0, default otherwise.
Targets linking with default render implementation:
- video_engine_tests
- video_loopback
- video_replay
- anything dependent on webrtc_test_common
Targets linking with internal render implementation:
- vie_auto_test
- video_render_tests
- libwebrtcdemo-jni
- video_engine_core_unittests
GN changes:
- Not many since there is almost no test definitions.
Work-around for chromium:
- Until chromium has updated libpeerconnection to link with video_capture_impl and video_render_impl, webrtc target automatically depends on it. This should fix the FYI bots and not require a webrtc roll to fix.
Re-enable android tests by reverting 7026 (some tests left disabled).
TESTED: passes all the bots. If this inadvertently breaks a target please fix the linking rules so the target has the desired implementation linked in.
BUG=3770
R=kjellander@webrtc.org, pbos@webrtc.orgTBR=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19359004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7217 4adac7df-926f-26a2-2b94-8c16560cd09d
into its own targets. Dependencies must link directly with the desired one.
Targets linking with libjingle_media:
- internal implementation when build_with_chromium=0, default otherwise.
Targets linking with default/external capture implementation:
- anything dependent on webrtc_test_common
- anything dependent on video_engine_core
Targets linking with internal capture implementation:
- vie_auto_test
- anything dependent on webrtc_test_renderer
GN changes:
- Not many since there is almost no test definitions.
TESTED: passes all the bots. If this inadvertently breaks a target please fix the linking rules so the target has the desired implementation linked in.
BUG=3768
R=glaznev@webrtc.orgTBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7209 4adac7df-926f-26a2-2b94-8c16560cd09d
This reverts selected parts of r7014 to enable
rolling WebRTC in Chromium DEPS.
This works around the problem with GYP includes
being processed in the first pass (i.e. variables
cannot be used for paths). Using a dependency with
a path using a variable that is conditioned for
build_with_chromium being 0 or 1 solves the Chromium
build.
These changes will be restored once I've finished
a major GYP refactoring that will break out all
test related code (at least the parts that includes
the Android APK targets) into a separate chain
of GYP targets that are not processed when generating
projects for Chromium (which is why r7014 is breaking
the Chromium build).
BUG=3741
TESTED=Passing compilation of standalone using:
GYP_DEFINES="OS=android component=static_library fastbuild=1 target_arch=arm" webrtc/build/gyp_webrtc
ninja -C out/Debug
Then verified the *_apk targets are generated and compiled.
Passing compilation from a Chromium checkout with third_party/webrtc
directory removed and a new empty third_party/webrtc mapped to the
standalone checkout using:
sudo mount --bind /path/to/trunk/webrtc third_party/webrtc
Then running build/gyp_chromium
I also verified WebRTC GYP targets exist and are able to compile.
R=henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7040 4adac7df-926f-26a2-2b94-8c16560cd09d
Restructure how the Android APK tests are compiled now
that we have a Chromium checkout available (since r6938).
This removes the need of several hacks that were needed when
building these targets from inside a Chromium checkout.
By creating a symlink to Chromium's base we can compile the required
targets. This also removes the need of the previously precompiled
binaries we keep in /deps/tools/android at Google code.
All the user needs to do is to add the target_os = ["android"]
entry to his .gclient as described at
https://code.google.com/p/chromium/wiki/AndroidBuildInstructions
Before committing this CL, the Android APK buildbots will need
to be updated.
This also solves http://crbug.com/402594 since the apply_svn_patch.py
usage will be similar to the other standalone bots.
It also solves http://crbug.com/399297
BUG=chromium:399297, chromium:402594
TESTED=Locally compiled all APK targets by running:
GYP_DEFINES="OS=android include_tests=1 enable_tracing=1" gclient runhooks
ninja -C out/Release
checkdeps
R=henrike@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22149004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7014 4adac7df-926f-26a2-2b94-8c16560cd09d
This will enable some low-level webrtc logging in a Chromium build,
while limiting the binary size impact.
For a Mac Release build, it results in an increase to Chrome.app of 37k
and libpeerconnection.so of 25k. For comparison, enabling full logs
costs 230k and 218k respectively.
BUG=b/11470432
TESTED=voe_cmd_test produces logs of the appropriate severity.
R=fischman@webrtc.org, henrikg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/3479004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5097 4adac7df-926f-26a2-2b94-8c16560cd09d
