[gpsd-dev] build, test, QA and CI

[Christian Gagneraud]

Hi all,

I haven't been very verbose recently, but I'm still working on some bits 
and bobs:

* code coverage:
It requires heavy refactoring of the test framework (need for pre and 
post hook per testapp, testcase and testsuite)

State of the report: http://fjorgyn.chgans.co.nz/pub/gpsd/20131104/
I've added aggregation by "testsuite" and "log file", but there are 
still some known issues, at this point it doesn't make sense to me to 
keep hacking ad-hoc scripts "out-of-the-tree"

* test framework
I've found one python test framework that support seamlessly parallel 
execution (can't remember which one, I don't have the box here), I tried 
it on gpsd and it simply works and allows me to install my coverage 
hooks and manage testsuites, testcases, aggregation, ...
Running tests in parallel breaks gpsfake (listening port conflict), and 
it breaks coverage as well due to concurrent process execution (gcov 
limitation, the work-around would be to use a dedicated directory per 
run, not sure it's worth the hassle)
I have another POC for this but on a machine that I can't currently access.
I didn't go further because this would be quite an invasive patch and 
there's lot of work to do if we want to go this way.
Another advantage I see with this solution is that it's all python 
based, so it should integrate very well with scons and gpsfake.

The test framework is a *show stopper* for code coverage integration.

* Source code documentation:
I'm having hard time to understand the architecture of gpsd and its 
associated tools and libs (who does what and why?) and the source code 
organisation (everything in the root dir), I'm spending lot of time 
going though SConstruct and the source files, reading code comments and 
all the doc/* and www/*.

What about using Doxygen? Would you accept patches that touch only 
documentation and comments?

* Continuous integration:

I have recently set-up a jenkins server at work for an internal project 
that provides tracking of (read: graphical trends):
- build status (of course!)
- test status (of course!)
- gcc warnings
- copy/paste detection
- code coverage
- llvm scan-build
- SLOC count
- TODO and FIXME tasks

On a separate project I started to investigate multi-platform build and 
test using on demand virtual machine acting as slaves (using libvirt and 
qemu), I successfully set-up OpenBSD 5.4, FreeBSD 9.2, Fedora 19, and 
OpenSuse 12.04 on x86_64 VMs, and a Debian 7.2 on mipsel (little endian)
This approach sounds very interesting to me, as it allows you to test on 
plenty of OS/CPU combination:
- OS: Linux flavours, BSD flavours, Unix flavours (I don't have any 
license for Windows or Mac OS)
- CPU: arm, x86, Sparc, Mips, PowerPC architecture, 32 and 64 bits, big 
and little endian
I even tried the experimental arm64 port, without much success :(

Another interesting approach with VM is that you can set-up jenkins to 
always use the same initial disk image, this could be used to track gpsd 
dependencies per platform for example: you start with a "bare" system, 
and the first step of your build is dependencies installation (eg. run 
contrib/ci/install-deps.sh), another advantage is that you can install 
gpsd before running the tests and get rid of the specially built 
libraries (which doesn't work when used with coverage BTW, for now I'm 
building gpsd with "coverage=True static=True")

Far from being ready I setted up jenkins on one of my public server and 
I'm willing to "offer" some resources to gpsd if people are interested. 
This is a decent server (address@hidden, 16GB of RAM and 3TB of disk), and 
should be up for the job.

We could use it for gpsd master and why not an hypothetical 
test-framework branch (hosted on github for example, pull request are 
very convenient for contributors)

* Copy/paste detector: http://pmd.sourceforge.net/snapshot/cpd-usage.html
This is really an interesting tool and integrates very well with Jenkins 
when configured to output XML report, attached is a text report of 
current gpsd head.

* Random stuff:

GNUradio:
Anyone have been playing with GNU radio?
Last year I used a cheap DVB-T receiver to make an SDR AIS receiver (not 
as good as a real one, but it costs only 20$!), and recently I 
discovered that you can do the same to make a .... SDR GPS receiver! See 
http://www.gnss-sdr.org

ADS-B:
Me too, I would like to see ADS-B support into gpsd, you can build your 
own SDR receiver with GNUradio as well... I do agree with ESR when it 
comes to standards and decoding references, but there's plenty of 
windows freeware around and some opensource stuff (like 
https://www.cgran.org/wiki/gr-air-modes)

Chris

gpsd-cpd-report-944914b.txt
Description: Text document