Make it compile with newer gps api
make it somehow working with new libgps api

quite interesting IRC talk about libgps api:

[08:56] <radekp> libgps so is so big crap, i cant believe...
[08:57] <radekp> is it normal for any sane library to change the api so that functions parameters are randomly added/removed?
[08:57] <radekp> some functions removed
[08:58] <radekp> and they dont even bother to update the manual or even make comment in header file
[09:07] <ynezz> but they'll welcome patches :)
[09:09] --> chris38 has joined this channel (~chris38@freedom.rd.francetelecom.com).
[09:13] <PaulFertser> radekp: hm, are you sure it's that bad? I know Eric cares a lot about such things. Are you probably comparing some really old version to a recent one?
[09:17] <PaulFertser> In fact, everyone is specifically asked to use libgps as opposed to gpsd protocol to provide a stable API while having flexibility to extend the gpsd socket API (it's now JSON-serialised btw, not the same as it was with old gpsd (w, p etc)).
[09:18] <radekp> hmm i have the opposite feeling...
[09:18] <radekp> i have app that worked fine on debian lenny, now it does not compile on squeeze
[09:19] <radekp> because of incompatible api
[09:20] <radekp> and i am scared that once i fix it for squeeze it will break again on wheezy...
[09:24] <radekp> ups yup it seems it is really the case and it's really crazy
[09:24] <radekp> so i have now libgps-dev on squeeze
[09:24] <radekp> extern bool gps_waiting(struct gps_data_t *);
[09:25] <radekp> and in git there is:
[09:25] <radekp> extern bool gps_waiting(const struct gps_data_t *, int);
[09:25] <PaulFertser> radekp: i think lenny is really old, what gpsd version was it back then?
[09:25] <radekp> they have added again argument
[09:26] <radekp> PaulFertser: well no idea, but it look that they are trying really hard to break all programs that use their api
[09:28] <radekp> or at least make the programs full of ifdefs
[09:29] <radekp> so there are now 3 debian releases, lenny, squeeze, wheezy - each have different api - either removed functionality or same functions with different arguments
[09:30] <radekp> even gps_open function is different, well this is crazy...
[09:32] <radekp> it looks i'll have to write two programs one with #ifdef GPSD_API_MAJOR_VERSION
[09:32] <radekp> for 4 version
[09:32] <radekp> and second program for version 5
[09:33] <radekp> hmm i hopy there will be no version 6 ;-)
[09:33] <radekp> s/hopy/hope
[09:37] <pabs3> lenny is EOL so ignore it
[09:41] <PaulFertser> radekp: that change you're talking about is "release-2.95-1005-g2663033". I.e. it's pre-3.0, Mar 2011. I think it's fair for ESR to make that change for 3.0 series.
[09:42] <radekp> i am not saying i cant live with it, but e.g. windows api or linux kernel is stable for years
[09:43] <radekp> if you want to add argument to function in C api, then you should create new function and e.g. mark the old deprecated
[09:43] <PaulFertser> radekp: well, it was a major shift for gpsd, and keeping old API doesn't look reasonable. Why support anything pre-3.0 anyway?
[09:44] <radekp> i have no idea about their version numbers, but squeeze and wheezy is just like 2 years
[09:45] <PaulFertser> And you'd need to ensure that old function is still working correctly etc. Linux, the kernel, is the kernel, it can't break api that way indeed. But for a userspace library i'd guess that's ok. Especially given you can link against the old library if you want it, and it'll work with the newer gpsd version hopefully.
[09:46] <radekp> but e.g. adding or removing args from the same function will segfault in some cases
[09:46] <radekp> or corrupt your memory - whatever...
[09:46] <PaulFertser> No, I mean you want the old library, and you link against it and you drag it in. I do not mean use an old header file to link against a newer library.
[09:47] <PaulFertser> The so version would be different so libraries can coexist on a single system.
[09:49] <radekp> yup i got the point, but still it's crazy to use such lib
[09:50] <PaulFertser> I'm sure Eric has some well-justified reasoning about why he decided to change arguments for a function instead of creating a new one.
[09:50] <lindi-> I'm not so sure to be honest :)
[09:51] <radekp> well it looks rather cosmetic to me
[09:51] <radekp> extern /*@null@*/struct gps_data_t *gps_open(const char *, const char *);
[09:51] <radekp> extern int gps_open(/*@null@*/const char *, /*@null@*/const char *,
[09:51] <radekp>      /*@out@*/struct gps_data_t *);
[09:52] <radekp> the first returns gps_data while the other sets pointer
[09:54] --> ao2 has joined this channel (~ao2@2001:1418:117::1).
[09:54] <radekp> the second is newer one - you can rename it to gps_open2() and keep the api compatible
[09:56] <lindi-> in 2004 it was int gps_open(char *device_name, int device_speed);
[09:56] <lindi-> later in 2004 it became int gps_open(struct gps_data_t *gpsdata, int timeout, char *host, char *port);
[09:56] <radekp> funny is that even test programs in their git dont compile with the new api
[09:56] <lindi-> then in 2009 it was split to gps_open and gps_open_r
[09:57] <lindi-> where gps_open returned a pointer and gps_open_r returned int
[09:57] <lindi-> I guess the original gps_open used static memory since gpsd does not use malloc
[09:57] <lindi-> s/gpsd/libgps/
[09:58] <apt> lindi- meant: I guess the original gps_open used static memory since libgps does not use malloc
[09:58] <lindi-> then in 2010 gps_open_r was removed and gps_open changed to act like gps_open_r
[09:58] <lindi-> "* gps_open() becomes reentrant, what gps_open_r() used to be."
[09:59] --> stefan_schmidt_w has joined this channel (~stefan_sc@62.6.189.26).
[10:02] <PaulFertser> Let's just ask him?
[10:03] --> bluelightning has joined this channel (~paul@83.217.123.106).
[10:03] <-- bluelightning has left this server (Changing host).
[10:03] --> bluelightning has joined this channel (~paul@pdpc/supporter/professional/bluelightning).
[10:04] <PaulFertser> Here is a report by one of the gpsd maintainers: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648496
[10:06] --> vanous has joined this channel (~vanous@robe.ludik.cz).
[10:10] <radekp> it would be best to ask him, if he could keep stable api for a few year - such project are really scaring off developers...