Expand Travis CI Build Matrix

[TafThorne]

We should try to expand the Travis build matrix to cover as many cases as we can. musl-gcc looks like an easy one to add. Several of the recent Issues and Pull Requests have been about build issues: #207, #188, #167, #217, #214, #211.

[afbjorklund]

Unfortunately Travis doesn't have so many platforms to test on, and the Ubuntu is quite old (no gcc-7).

[afbjorklund]

Darnit...

> ping -c 3 -i 0.2 -w 1 127.0.0.2
 icmp open socket: Operation not permitted

[afbjorklund]

@TafThorne : not sure it is worth it, there is not much that we can test ?
And the musl-gcc build doesn't work with python, so it fails the "check".

It would be more interesting to fix long-standing bugs, such as slots (#161) ?
But adding "libavahi-client-dev" could be a good idea, since it is default.

@@ -5,6 +5,7 @@ addons:
         packages:
             - python3-dev
             - libiberty-dev
+            - libavahi-client-dev
 
 before_script: ./autogen.sh

[TafThorne]

Well if we have done most of what we can with Travis that is fair enough. My motivation is that I do not have many resources to work on this project with. I can review code online and act based on others results or comments but not much else. At least if a build passes I can see some aspect of the risk a patch poses.

I'll try and look over the 3.2 branch soon. The branch #178 works on 3.2 does not seem to match the v3.2rc1 change-set exactly. There are some 62 commits between the two at present that need at least a quick eyeballing before the new version is rubber stamped. Though I guess I could make v3.2rc1 into v3.2.0 then the head of branch v3.2.1 or something.

[HenryMiller1]

[maintainer of icecream here]

Icecream is able to run a number of build tests. I don't know if our setup would work for you (look - you might be inspired). Our basic idea is start more than one daemon on different ports, and use one to compile something and verify via daemon logs that it was built on a different one.

If I understand distcc correct the port concept doesn't make sense, but I think that you can leverage docker to do better than what we are doing. I would suggest createing a User-defined network in docker, run distcc in several different containers connected to that docker and then start a build in one and verify that the build goes to the others.

Running tests like this on icecream has found/prevented a lot of bugs. In particular we run address sanitizer and undefined behavior sanitizer builds against those tests. (we can also run valgrind but currently are not testing that)

I would suggest that by creating a test suite and then running sanitizer builds against it you can do a lot more than it looks like you are doing.

[HenryMiller1]

I see you have a test suite, though I'm not clear on what it tests. Maybe it is already enough?

If nothing else creating sanitzer builds and getting them green is an obvious thing that we found very helpful..

[afbjorklund]

@HenryMiller1: Clang builds and sanitizers, is definitely a good idea. We have those in ccache, so I know how to set it up with a Travis matrix...

The end-to-end tests are also great, but would require more work to set up. I don't think there's enough developers to set it up and maintain it ?

[martinm82]

We were investigating icecream and now distcc for macOS environments. Icecream unfortunately has an issue which would block us and therefore we started looking into distcc.
In our fork we are trying to fix some clang/osx issues and have as well extended the build/test matrix for Travis.

Unfortunately I needed to fix some tests to make them work with clang and gcc. So the changes are definitely not ready to be merged but a first start to get the builds green.

https://travis-ci.org/tt-gf/distcc/builds

[andy5995]

Related PR at #469