Re: [gpsd-dev] Mingw port

[address@hidden]

Hello,

i have done a few basic investigations using the library as a windows dll too, 
the only a bit problematic file i found is netlib.c.
(An openCPN on windows with an network connection to a gpsd would be great...)

Do you expect to have a source tree, where i can compile libgps.dll for a 32 
bit and/or a 64 bit windows, ready within the next few weeks?

Regarding the port of the daemon to windows, i can provide and test the 
nmea2000 part.

Reinhard 

-----Original-Nachricht-----
Von: Ukygerkgubiekd Ukygerkgubiekd <address@hidden>
An: "address@hidden" <address@hidden>
Cc: "address@hidden" <address@hidden>
Betreff: Re: [gpsd-dev] Mingw port
Datum: Thu, 09 Aug 2012 14:52:51 +0200

Regarding serial.c and gpsd.c: yes, these are problematic for a Windows 
port. But I now feel that this is a problem for later on.


>From Googling, it seems to me that most Windows users interested in GPSd 
want a libgps.dll (==libgps.so) that they can call into from their GUI 
programs.There seems to be much less demand for a fully-featured daemon on 
Windows.
I imagine this is partly 
because many vendors ship poor-quality Windows software with their 
devices, but it's probably also partly due to the fact that Windows is more 
often used to run client-side GUI programs than UI-less server daemons like 
GPSd.


My experience with the mingw 
branch has taught me that a client-only port can be done much more 
easily and more cleanly than a full daemon-too port.So I feel that if we ever 
do a daemon port to Windows, we should do it only after a client-only port has 
been bedded down.

Consequently I believe we should proceed as follows:

1. Get preparatory cleanups in (see my previous message), then
2. Gradually trickle in only the client changes from the mingw branch, 
cleaning them up as I go, and this time in more granular commits that are 
each 'obviously right'; then
3. Pause one release, watch for regressions, give everyone a good opportunity 
to read/criticise/improve the changes so far; then
4. Commence a better-informed discussion about how to get a fully-featured 
daemon 
working on Windows *without* littering the source tree with Win32 API
 calls and '#ifdef _WIN32', but also without re-inventing Cygwin.

It may be that the outcome of 4 is that the ugliness is too high, and the 
demand too low, to proceed with a daemon-too port.
That would be rather sad, but even then we would have accomplished a useful 
client-only Windows port.

Regards,

Matt



----- Original Message -----
From: Eric S. Raymond <address@hidden>
To: Ukygerkgubiekd Ukygerkgubiekd <address@hidden>
Cc: "address@hidden" <address@hidden>
Sent: Tuesday, 31 July 2012 2:09 PM
Subject: Re: [gpsd-dev] Mingw port

Ukygerkgubiekd Ukygerkgubiekd <address@hidden>:
> However, Windows has a completely different set of APIs for serial comms, and 
> for timing/handshaking/waiting etc.
> 
> To get drivers, the daemon and the regression tests working under Windows 
> hence requires some abstraction layer over those differences.
> 
> My idea is that such a layer could also incorporate the existing differences 
> between shm, dbus, QT, sockets and fds.
> Your comments appreciated!

Sounds useful if done right, but quite ugly and obtrusive if done wrong.

I am, at least, open to refactoring changes that would narrow thw coupling to 
the base OS.  Most of the changes would be in gpsd.c and serial.c, correct?
-- 
        <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>