gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Mingw port


From: Ukygerkgubiekd Ukygerkgubiekd
Subject: Re: [gpsd-dev] Mingw port
Date: Thu, 9 Aug 2012 07:53:04 -0700 (PDT)

Hi Reinhardt,

OpenCPN looks very cool, and is exactly the sort of use case I had in mind. I'm 
glad to hear I'm not alone!

However, I'm sorry to say, a client-only port to Windows that is clean enough 
to merge into mainline is almost certainly more than a few weeks away.

For something immediate, you could look at the existing mingw branch.
It's suitable as a source of inspiration for future cleaner changes, but 
probably not as a base to work from.That said, it's here:

https://github.com/ukyg9e5r6k7gubiekd6/gpsd/tree/mingw

This compiles to a libgps.dll and some client executables built on it, 
including a cgps.exe that can connect to a remote port 2947.
However, I never actually tried to connect any of the executables to a running 
gpsd - I was only trying to map out the problem space.
I expect there will be dumb and easily-fixed bugs lurking in netlib.c, due to 
mismatches between BSD sockets and winsock.

It needs pdcurses and pthreads-win32 (both open source) to build and run.

So far I only built this for 32-bit Windows, using both a 32-bit-Linux-hosted 
mingw32-target cross compiler, and also a native Windows mingw32 compiler.
I think it would compile cleanly under mingw-w64 (native or cross-compiler) 
too, but I never actually tried that.

Under Windows, building the mingw branch from source goes like:
1. Point scons at the mingw compiler using (for example) "target = 
'i686-w64-mingw32'"
2. Run scons from a Cygwin shell to generate gpsd.h, gpsd_config.h etc. No need 
for rest of Cygwin compilation.
3. From a mingw shell, build using 'make -f Makefile.mingw'.

Obviously, this is far from ideal. It's like this because mingw native builds 
of python and scons don't seem to be readily available, nor easily creatable.

Thank you very much for your offer of testing nmea2000 support on Windows.
I'll certainly need your help with this, as I don't have nmea2000 hardware here.

Herzliche grusse,

Matt


----- Original Message -----
From: "address@hidden" <address@hidden>
To: Ukygerkgubiekd Ukygerkgubiekd <address@hidden>; address@hidden
Cc: address@hidden
Sent: Thursday, 9 August 2012 11:13 PM
Subject: Re: [gpsd-dev] Mingw port

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>




reply via email to

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