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 protected]
