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.
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_
So the RFE for some stoopid #define that carries a version stamp
that can be tested is quite predictable.
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
... this is POPT 2.0 ...
... this is NOT POPT 2.0 ...
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
Its all a crock and all unneded for a toy library like POPT (jmho, ymmv),
but the RFE is predictable no matter what.
73 de Jeff
Received on Fri Jun 18 16:52:50 2010