[gpsd-dev] RFC: libgps on Windows

[Robert Norris]

RFC: libgps on Windows.

As the maintainer of Viking[1], I've been recently asked[2] to include 
accessing GPSD on a remote Linux host whilst running on Windows.

I agreed that this should be reasonably straight forward - especially I as now 
have a setup to cross compile for Windows from Linux.

However upon investigating a cross compile of just the libgps component of 
GPSD, I found several issues that made this a little more work than 
anticipated. NB I have *no* desire to try to make gpsd a Windows service or 
make Windows versions of cgps, gpxlogger, etc...

1. No ability to compile just the libgps component

Allow turning off (but defaulted to all on) building various high level 
components: libgps, libgpsd, gpsd and gpsdclients (aka cgps, gpxlogger etc...)
Thus if one turns off stuff you don't need it will only build whatever is left 
e.g.:
scons libgpsd=False binaries=False dbus_export=False shm_export=False

2. Dependencies of libgpsd on libgps (and that building libgps depends on 
gpsd.h)

IMHO libgps should only contain code that fulfils the API of gps.h
gpsd.h has dependencies on things that are either not fully cross platform 
(e.g. termios.h) or describes various types that are internal to GPSD such as 
gps_device_t.
Thus currently the code needs some reordering and various small changes so that 
libgps can be built standalone (and so that gpsd and other binaries can be 
built too).
Some functionality is outside the scope of libgps or libgpsd but used in 
binaries, e.g. daemon()
Conceptually code for libgps should not depend on gpsd.h and any shared 
definitions can be put in gpsd_config.h or be shared/described via new header 
files.
Generally this eases the amount of cross platform code needed to generate just 
libgps.

3. Cross platform sockets in netlib.c

I'm aware of some previous efforts to make gpsd cross platform[3].
By limiting cross platform support to just the socket component, I hope this 
work is much more likely to be accepted into the gpsd code base.

4. Allow generation of libgps.dll
ATM I have had to put in detection of the target type into the SConstruct file 
to set the required SHLINKFLAGS + SHLIBSUFFIX variables to generate a DLL
Ideally setting up the variables should be able to come from the invoking 
command line and/or environment
but so far I've not been able it get it to work this way.

5. Update 'Hacking.html' for the The software-layering view to describe that 
gpsd breaks into five pieces (not 4): the drivers, the packet sniffer, the core 
gpsd library, the client gps library and the multiplexer.
... The core gpsd library allows for control of the session via shared memory, 
DBUS or network sockets...
... The client gps library is how any external code can interact with GPSD.
Limitation: The client gps library on Windows only supports network socket 
session management...

Thus I plan (and have in various stages of work) patches for all of the above.

ATM I have a libgps.dll (but not even sockets build into it) that Viking can 
build, link and run against.

Hopefully this is an agreeable way forward and I'd be grateful for any feedback.

[1] https://sourceforge.net/projects/viking/
[2] https://github.com/viking-gps/viking/issues/11
[3] https://github.com/ukyg9e5r6k7gubiekd6/gpsd/tree/mingw

-- 
Be Seeing You - Rob.
If at first you don't succeed,
then skydiving isn't for you.