Changes differing from https://webrtc-codereview.appspot.com/37859004:
* I put the include_tests==1 stuff of audio_coding.gypi in its
own audio_coding_tests.gypi file, including the Android and isolate
targets which were incorrectly located in the previous CL
* I moved the bwe utilities in remote_bitrate_estimator.gypi
into include_tests==1 since they depend on test.gyp after I
cleaned up the duplicated inclusion of rtp_file_reader.cc
R=stefan@webrtc.orgTBR=tina.legrand@webrtc.org
TESTED=Passing gyp and compile using:
webrtc/build/gyp_webrtc -Dinclude_tests=1
webrtc/build/gyp_webrtc -Dinclude_tests=0
I also setup a Chromium checkout with my checkout mounted in
third_party/webrtc and ran build/gyp_chromium successfully.
BUG=4185
Review URL: https://webrtc-codereview.appspot.com/33159004
Cr-Commit-Position: refs/heads/master@{#8205}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8205 4adac7df-926f-26a2-2b94-8c16560cd09d
This required to move the AGC tools source files
into webrtc/tools and create a new agc_test_utils target.
Since audio_codec_speed_tests.gypi referenced sources above,
the best approach I could come up with was to add an audio_coding.gypi
file at a higher level and move the targets in there (+ the includes from
modules.gyp which is an improvement IMO).
I also added a PRESUBMIT.py check to prevent new source
entries being added with <(webrtc_root) in the path.
BUG=4185
R=andrew@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37859004
Cr-Commit-Position: refs/heads/master@{#8197}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8197 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
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
Most of these changes were done in r7014, but a few targets
were missed. This should make these tests run better
(but they might still be failing due to webrtc:3764).
BUG=webrtc:3741
TESTED=Local compilation using:
GYP_DEFINES="OS=android component=static_library fastbuild=1 target_arch=arm" webrtc/build/gyp_webrtc
ninja -C out/Debug
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7019 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
Plays back rtpdump files from Wireshark in realtime as well as save the
resulting raw video to file. Unlike the RTP playback tool it doesn't
support faster-than-realtime playback/rendering, but it instead utilizes
the same path as production code and also contains support for playing
back FEC.
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16969004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6838 4adac7df-926f-26a2-2b94-8c16560cd09d
From now on it is expected that code linking system_wrappers.gyp:system_wrappers
provides an implementation for field_trial API or links with the default one in
system_wrappers.gyp:field_trial_default.
Note: Since there is no use of webrtc::field_trial API inside webrtc this CL on
itself does not forces the clients to actually define it. It however lays the
API and updates the gyp rules to link with so that it is ready to use.
Tested: Introduced a use of field trial in system wrappers and make sure all
bots were building successfully.
BUG=crbug/367114
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14489004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6147 4adac7df-926f-26a2-2b94-8c16560cd09d
The performance test is based on the neteq4_speed_test application. The
bulk of the test code is extracted into a test class, and included into
the neteq_unittest_tools target. The actual gtest that runs the
performance test is implemented in neteq_performance_unittest.cc, and
built as a part of webrtc_perf_tests.
The old stand-alone test application is now made dependent on the new
test class, to avoid code duplication.
BUG=2397
R=andrew@webrtc.org, kjellander@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6749004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5362 4adac7df-926f-26a2-2b94-8c16560cd09d
