[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] [PATCH 4/4] Parallelizes gps-regress and gps-makeregress.
From: |
Fred Wright |
Subject: |
Re: [gpsd-dev] [PATCH 4/4] Parallelizes gps-regress and gps-makeregress. |
Date: |
Thu, 3 Mar 2016 17:23:11 -0800 (PST) |
On Fri, 4 Mar 2016, Robert Norris wrote:
[...]
> 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?
I think it would make more sense to leverage gpsfake (or at least
gps/fake.py) to create a test instance of the daemon, as it already does
for the regression tests. It's also proven to be parallelizable. :-)
Fred Wright