Re: [gpsd-dev] [PATCH 4/4] Parallelizes gps-regress and gps-makeregress.

[Robert Norris]

> Date: Tue, 1 Mar 2016 15:48:52 -0800
> From: address@hidden
> To: address@hidden
> Subject: Re: [gpsd-dev] [PATCH 4/4] Parallelizes gps-regress and 
> gps-makeregress.
>
> [...]
>
> The purpose of 'check' is to run a particular subset of the tests.
> Verifying that tests that it's *not* running build properly is beyond its
> job description. Every test that it *does* run depends on the programs it
> needs, so adding 'testprogs' to 'check' is completely redundant. If you
> want to make sure that everything builds, build everything. :-) Perhaps a
> 'buildall' target would be useful, but "scons build testprogs" works now.
>
> Probably the *real* issue in this case is that 'check' doesn't include
> *running* test_gpsmm, but that would be nontrivial since it requires a
> running daemon instance.
>

We may be able to auto check test_libgps - this works for me on Linux:

# Sleep to give chance for gpsd to get ready before attempting to join it
Utility('test-libgps', [gpsd + test_libgps], [
    '$SRCDIR/gpsd -F `mktemp -u -t gpsd.pid-XXXXXXXXXXXXXXXXXXXX` && sleep 1 && 
'
    '$SRCDIR/test_libgps -f "?DEVICES;" | grep "^flags: (0x" && '
    'pkill -n gpsd'
    ])

Some issues are:
1. Won't work if gpsd is already running (as it will have claimed the default 
port)
2. Do these commands work on all supported platforms
3. Won't work in parallel if other new tests are added this way (e.g. a 
test-gpsmm case) as it would introduce conflicts on when gpsd is 
started/stopped.

ATM test_gpsmm doesn't exit until gpsd stops, but I've added a mode to return 
for this type of (limited) automated checking.

Is this worth doing?