[Hamlib-developer] Re: Patches for FreeBSD, part I
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Stephane F. <f8...@fr...> - 2002-09-01 22:25:33
|
On Fri, Aug 30, 2002, Michael Smith wrote: > Attached you will find the first 3 patches required to get hamlib to compile on *BSD. They are all rather tame, so I would appreciate someone with developer access to CVS to apply them, make sure the linux build doesn't break, and commit them. Sorry to be a bit picky, your patches are fine for *BSD, but they could be even better for non BSD system that are *BSD like. Besides, this is the whole philosophy behind autoconf. Do not test for a system, but rather for the existence (or lack thereof) of a feature. In other words, I would like to get rid of "#if !defined(BSD)". For event.c.patch, it looks trivial since it can be done by detecting presence of F_SETSIG. serial.c.patch looks harder since I don't know why "include <termio.h>" breaks. Does *BSD have both TERMIOS and TERMIO? Can you tell us? May be the right fix would be: #ifdef HAVE_TERMIOS_H #include <termios.h> /* POSIX terminal control definitions */ #else #ifdef HAVE_TERMIO_H #include <termio.h> #else /* sgtty */ #include <sgtty.h> #endif #endif NB: added 'else' statement after HAVE_TERMIOS_H > I am still working on patches for rpcrig and rpcrot, and will post them as soon as they are ready. They'll be very welcome. Be careful, for rpcrig and rpcrot, some files are auto-generated. > I also have a question for the group: Is the maintainer of the os456/os535 code still active? I own an os456, and have features and updates that I'd like to integrate into hamlib, but I don't want to step on any toes. John R. Marshall helped on the Optoscan 535, I don't know if he's still around. If anyone feels concerned with the os456/os535, please stand up. Now talking about the new features you want to add to this backend that would require a modification of the API, you'll have to first expose it to the list, and then get the approval from me. This is to keep the coherency of the API among the different backends. Note: backend maintainers are free to make internal changes on their own, as long as they agree with other developpers if any. 73 Stephane |