On Thu, Dec 21, 2006 at 07:44:17AM -0700, we recorded a bogon-computron collision of the <[EMAIL PROTECTED]> flavor, containing: > >I think I prefer the "add as needed" to the "expose unhappy > >incompatibilities" approach. But I think that the 4.x API is more likely > >to be stable enough for now that it probably is six of one and half-a-dozen > >of the other. Looking more carefully at the map_cache code, the API change > >that was incompatible in early versions of 4.x was between 4.0 and 4.1, not > >between 4.1 and 4.2. So it's been pretty stable for four or five minor > >versions, and it's probably OK to assume it'll stay stable until 5.x, at > >which time it'll probably be completely unstable again. > > > Wouldn't it be better for xastir to report "incomputable version" and > then recommend the Wiki site for a fix? Might be one way to do it.
Well, it might be difficult. Ideally, the configure probe should search for the presence of the functions we need to have in the bdb library, and report that they're not found. That's what we're doing now, but searching all over the place for the library first. As long as it's possible to tell the differnce between compatible and incompatible versions at configure time, what you suggest is OK, and is in fact what's already happening to a degree. An example of such an incompatibility is between versions 3.x and 4.x, where a function we need doesn't exist in the former --- if one were simply to add "db3.x" directories to the huge list of directories we search in, it's fail because the function isn't there even though the library exists. But db4.0 has that function, it just takes different arguments than it does in all subsequent versions -- something that is more difficult to check in autoconf (not impossible, but not doable with the stock macros, as they only probe for the existence of functions in a library, not their prototypes). Were there no special case ifdefs in map_cache to handle 4.0, the configure script would scream along thinking everything is copacetic. In this particular case, if there were no special case ifdef it is likely that xastir would compile and link just fine (maybe with warnings about incompatible function prototype or something), but then bomb when run because the arguments passed to the function would be wrong. Who knows how we'd detect an incompatibility in versions that don't exist yet. Best not to probe for things we don't know to work, and add new versions after carefully checking as they get released. Better still to remove dependence on unstable libraries, but that's actual work for someone with time to do it. -- Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM "And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit!" --- The Tick _______________________________________________ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir