[Top][All Lists]
[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>