gpsd-dev
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]