RPM Community Forums

Mailing List Message of <popt-devel>

POPT 2.0: version stamping in includes

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 18 Jun 2010 - 16:52:22 CEST
Message-id: <7331AF65-8FD1-4F5D-A084-1BC32B1BA584@mac.com>
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
Received on Fri Jun 18 16:52:50 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.