making neteq_unittest_tools always available

making neteq_unittest_tools always available

BUG=None

[mbonadei, 2017-04-27 09:29:02]

Description was changed from

==========
making neteq_unittest_tools always available

BUG=
==========

to

==========
making neteq_unittest_tools always available

BUG=None
==========

[mbonadei, 2017-04-27 09:29:02]

mbonadei@webrtc.org changed reviewers:
+ kjellander@webrtc.org

[mbonadei, 2017-04-27 09:37:46]

On 2017/04/27 09:29:02, mbonadei wrote:
> mailto:mbonadei@webrtc.org changed reviewers:
> + mailto:kjellander@webrtc.org

The error is:

ERROR at //third_party/webrtc/test/BUILD.gn:113:5: Can't load input file.
    "//third_party/gflags"

So the chromium trybot is basically trying to generate build files for
//third_party/gflags.
This CL only exposes:
 - webrtc/modules/audio_coding:neteq_unittest_tools
 - webrtc/modules/audio_coding:rtc_event_log_source

They were inside the if(rtc_include_tests) condition before this CL.

Gn 'path' command should help us spotting the dependency path between
two targets [1], but there are no dependencies:

$ gn path out/libfuzzer-no-tests
//webrtc/modules/audio_coding:neteq_unittest_tools 
//third_party/gflags --all
No non-data paths found between these two targets.

$ gn path out/libfuzzer-tests //webrtc/modules/audio_coding:neteq_unittest_tools

//third_party/gflags --all
No non-data paths found between these two targets.

$ gn path out/libfuzzer-no-tests
//webrtc/modules/audio_coding:rtc_event_log_source 
//third_party/gflags --all
No non-data paths found between these two targets.

$ gn path out/libfuzzer-tests //webrtc/modules/audio_coding:rtc_event_log_source

//third_party/gflags --all
No non-data paths found between these two targets.

[1] - Finds paths of dependencies between two targets. Each unique path will be
  printed in one group, and groups will be separate by newlines. The two
  targets can appear in either order (paths will be found going in either
  direction).

[mbonadei, 2017-04-27 09:58:28]

I confirm that 'gn path' was right.

It is not about pulling the dependency, it is about depending on a target
in the '//webrtc/test/BUILD.gn' file.

I commented the dependency on '//webrtc/test:rtp_test_utils' (disabling
'gn check' for that target) and now it is able to generate build files.

So, I think that when Gn parses a BUILD.gn file it is eagerly checking that
all the targets listed in that file are buildable.

In our case it breaks because '//third_party/gflags' is not buildable, because
chromium has their own flags library.

So, fuzzers are not the problem per se. The problem is that we cannot depend on
targets in '//webrtc/test/BUILD.gn' because that file is full of dependencies on
'//third_party/gflags'.

A possible solution is to refactor that BUILD.gn file so we can extract
libraries
in another BUILD.gn file and keep all the targets related to running tests in
another BUILD.gn file.

[kjellander_webrtc, 2017-04-27 10:44:48]

On 2017/04/27 09:58:28, mbonadei wrote:
> I confirm that 'gn path' was right.
> 
> It is not about pulling the dependency, it is about depending on a target
> in the '//webrtc/test/BUILD.gn' file.
> 
> I commented the dependency on '//webrtc/test:rtp_test_utils' (disabling
> 'gn check' for that target) and now it is able to generate build files.
> 
> So, I think that when Gn parses a BUILD.gn file it is eagerly checking that
> all the targets listed in that file are buildable.

Aha! I wasn't aware of this, but I've run into similar issues before. What we
could do is to hide
the problematic targets inside an if(!build_with_chromium) condition. That could
be an easier way. We might even be able to put such a condition in
third_party/gflags/BUILD.gn and try to work on getting some kind of standalone
build working with build_with_chromium=true (it has never worked in the past,
but I think it can be done).

> In our case it breaks because '//third_party/gflags' is not buildable, because
> chromium has their own flags library.
> 
> So, fuzzers are not the problem per se. The problem is that we cannot depend
on
> targets in '//webrtc/test/BUILD.gn' because that file is full of dependencies
on
> '//third_party/gflags'.

Great observation.

> A possible solution is to refactor that BUILD.gn file so we can extract
> libraries
> in another BUILD.gn file and keep all the targets related to running tests in
> another BUILD.gn file.

I think the easiest thing to try first is to hide the problematic parts of
webrtc/test/BUILD.gn using the approach above. Then we can do additional
refactorings if needed.

Please make sure you also communicate with hlundin@ since he's working on
https://codereview.webrtc.org/2845013003/