More administrivia related to "incompatibilities" There is no current means (because I've always thought versioning is a crock) to detect what POPT API version is being used.
(aside) Instead of versioning, I've always been ultra-careful not to introduce any incompatibilities into POPT's API/ABI. All that changes with POPT 2.0, a major release with _PLANNED_ incompatibilities. So the RFE for some stoopid #define that carries a version stamp that can be tested is quite predictable. (aside) Instead of a #define version, I typically us a "de facto" check for POPT in compatibilities. E.g. in order to use POPT 2.0 in rpm-5.3.2 I'll likely do #if defined(POPT_ARGFLAG_CALCULATOR) ... this is POPT 2.0 ... #else ... this is NOT POPT 2.0 ... #endif while idly waiting the necessary 2-3 years for the opportunity to use POPT code I wrote in RPM code I'm writing. Isn't it ironic? But I have a distinct edge "knowing" how to use POPT "portably" and so some silly version stamp is gonna be needed. I'll likely just steal the RPM versioning and push into POPT unless I hear other suggestions. Other suggestions might include a run-time API (like pcre/neon/openssl to mention 3 off the top of my head) that could be implemented so that one could track "features" which can be enabled/disable specifically into applications. Its all a crock and all unneded for a toy library like POPT (jmho, ymmv), but the RFE is predictable no matter what. Opinions? 73 de Jeff ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List email@example.com