RPM Community Forums

Mailing List Message of <popt-devel>

Re: POPT 2.0: version stamping in includes

From: Michael Jennings <mej@kainx.org>
Date: Sat 19 Jun 2010 - 03:03:27 CEST
Message-ID: <20100619010327.GF31998@kainx.org>
On Friday, 18 June 2010, at 20:31:28 (-0400),
Jeff Johnson wrote:

> But note run-time, where its not always possible to do the test,
> particularly if popt was built by vendors differently, or different
> versions or feature sets.
> What I was envisioning is merely a Bloom filter with an API like
> 	bool poptHasFeature(const char * s)
> Then during build the strings/aliases are pumped into a Bloom
> filter, and the resultant bitsset is just stashed into octets
> and fed to (already exists in popt-1.16)
> int poptBitsChk(/*@null@*/poptBits bits, /*@null@*/const char * s)
>         /*@*/;
> It would be quite a simple API, and reasonably general/extensible
> (depending on how the bitset was generated during build) without
> all the usuall "fluff" of tables of arrays of ptrs of ...
> ... but since POPT is unlikely to accumulate 32 "features" this century,
> well, it could just be a simple enum of "features" returned as an int32.

Ah, okay.  I guess I was envisioning for runtime checks:

  void *f = dlopen(NULL, RTLD_LAZY);
  if (dlsym(f, "popt_something")) {

But for cases where that's not possible, either of your ideas is

> Hmmm ... I suspect I'll be lazy and do nothing until I'm forced.

Spoken like a true engineer.  ;-)


Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@kainx.org>
Linux Server/Cluster Admin, LBL.gov       Author, Eterm (www.eterm.org)
 "You did not tell the truth, and so you will have to pay the
  consequences."                -- Bob Barker, "Truth or Consequences"
Received on Sat Jun 19 03:03:57 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.