Re: [gpsd-dev] [PATCH 2/3] Enable Windows version of gpxlogger

[Robert Norris]

> Here there's a choice between:
>
> 1) Offering an option that doesn't actually work (but AFAIK fails
> gracefully and informatively).
>
> 2) Cluttering the code with conditionals needed solely to support
> everyone's least favorite platform.

Initially I started with option 1), since it's obviously less code change and 
seemed alright for gpxlogger to simply complain.

However in gpspipe I didn't see a simple way for a failure mode in the serial 
port option, so I choose to disable it completely for Windows and so did the 
same for the daemonize option. Although now I see there might be way.

I don't think I've ever seen man pages on Windows.
For distributing libgps.dll, gpspipe.exe and gpxlogger.exe I was thinking of 
just offering the binaries only.

The man pages can often be found online (e.g. 
http://manpages.ubuntu.com/manpages/zesty/man1/gpspipe.1.html)

However it would seem strange to mention Windows issues in the man pages, when 
they there mainly for Unix like systems.
And especially as I've no plan for Windowizing any other gpsd items.

Perhaps a statement about Windows support would be better off somewhere in the 
www/ documentation.
Words along the lines of:

gpsd (the main service daemon) and most gpsd tools are for Unix like systems 
since this is where they are developed and tested.

Remote access over sockets via the C library and the simple command line tools 
of gpspipe and gpxlogger is supported.

gpxlogger/gpspipe have limitations X, Y, Z on Windows.


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

________________________________________
From: gpsd-dev <address@hidden> on behalf of Fred Wright <address@hidden>
Sent: 04 March 2017 23:13:32
To: address@hidden
Subject: Re: [gpsd-dev] [PATCH 2/3] Enable Windows version of gpxlogger

On Fri, 24 Feb 2017, Robert Norris wrote:

> Disable daemonize option which is not available on Windows.

Here there's a choice between:

1) Offering an option that doesn't actually work (but AFAIK fails
gracefully and informatively).

2) Cluttering the code with conditionals needed solely to support
everyone's least favorite platform.

It's also worth noting that there's currently no mechanism for conditional
manpage content, so #2 also makes the usage text inconsistent with the
manpage.

On that basis, I'd be more inclined to go with #1, perhaps with a "doesn't
work on Windows" note in the manpage (if manpages actually work on
Windows).  The "gracefully and informatively" part should be verified,
though.  I did change the error from EINVAL to EPERM, which seems more
appropriate.

> Add check for signal compatibility as SIGQUIT may not be available.

I added a default definition for SIGQUIT (as well as SIGHUP), so this
should be unnecessary (but should be tested on Windows).

Thus, I think for now at least, this patch can go away altogether.

Fred Wright