I. Introduction
Precompiled libraries for stable version of webrtc (those used in chrome) have been requested many times on the mailing list, but so far nobody as put him/herself at making them. One of the goal of this blog is to provide those to lower the barrier of entry for people that want to build on top of webrtc.
As I was preparing the libraries on linux, i bumped again in the failing test I mentioned in a previous post:
“The first error seems to be related to a bad allocation. That’s were you realize that running this on the smallest possible linux instance in AWS was possibly a bad idea. It should disappear when I host the Linux built bot on a bigger instance. The second error is more elusive, and I can’t figure it out just from the logs. Once I will have set up a more powerful linux build host, I will debug there directly.”
As far as I am concerned, having even a single test failing is a no-no. So I dug deeper. Here is the build before the changes.
II. Investigating
In the mean time, I moved the build bot to a stronger (c3.2x) instance. Indeed, the first error was a memory allocation problem triggered by an undersized instance, and went away without any special attention.
The second error was related to screen sharing tests, which is not a surprise given that we are running on a virtual machine without display.
The original tests are run through a test driver written in python. The code is separated from libwebrtc and can be found there. The main file is here. Here again, it is code coming from chrome which contains a lot of things not needed to test the standalone version of webrtc (chrome sandbox, …).
It also does a lot of nice things in term of checking that no left over from previous, possibly failing, tests are not on the way. There are a lots of extra steps that improve the stability and robustness of the tests, so it’s not all bad.
To make things simple, you just need to install Xvfb and openbox,
- sudo apt-get install xvfb
- sudo apt-get install openbox
then define a display, create it, and run the window manager before you run your test (the code below is written to stay as close as possible to google tests conditions).
- export DISPLAY=:9
- Xvfb :9 -screen 0 1024x768x24 -ac -dpi 96&
- openbox&
Now, all tests pass!
III. Conclusion
The greenness of the dashboard is something that is of utmost importance. If the dashboard dis not free you are developing blindfolded. Making it green is an everyday challenge,. It can be seen as too much to bother about, but it is actually a developer safety net, and allow you to focus on developing only.
The advantages of cmake here are twofold: lower barrier of entry, and collaborative dashboard.
Once again, one can see that the chrome build tools, however good and advanced, are an overkill in the case of the standalone libwebrtc. I do believe it is slowing down adoption of and contribution to webrtc, as one needs to become a chromium developer first, and the learning curve is steep.
In any case, you can now download tested, precompiled, libraries and headers for linux, mac or windows on the Tool page. If what you want is just to develop something against libwebrtc that work against the latest stable chrome, you have all you need now.
Some people request features that are not, or not yet, in webrtc. In a following post, I will explain how to patch libwebrtc effortlessly as part of the process described before.
Enjoy.
This work by Dr. Alexandre Gouaillard is licensed under a Creative Commons Attribution 4.0 International License.
This blog is not about any commercial product or company, even if some might be mentioned or be the object of a post in the context of their usage of the technology. Most of the opinions expressed here are those of the author, and not of any corporate or organizational affiliation.