Re: POPT 2.0: version stamping in includes
On Friday, 18 June 2010, at 21:09:24 (-0400), Jeff Johnson wrote: > Any idea how "portably" POSIX dlsym() is in 2010? According to the Open Group website, dlsym() and dlopen() are at *least* in POSIX.1 2004 if not earlier. And they came from SunOS, so Solaris portability won't be an issue. MacOS has them, BSD has them. They should be fine. > There's the GNUish dlvsym() that needs figgering if I attempt > "compatibility" with symbol versioning too. Yeah, that's where you'll get into portability trouble. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "Can we leave the world outside just for awhile, just for awhile? Spend some time, you and I, under this bright, glorious sky? It's been so long since I first saw you, but I still love the smile in your eyes." -- Roxette, "Church of Your Heart" __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: POPT 2.0: version stamping in includes
On Jun 18, 2010, at 9:03 PM, Michael Jennings wrote:
>
> Ah, okay. I guess I was envisioning for runtime checks:
>
> void *f = dlopen(NULL, RTLD_LAZY);
> if (dlsym(f, "popt_something")) {
>...
> }
>
Any idea how "portably" POSIX dlsym() is in 2010?
There's the GNUish dlvsym() that needs figgering if I attempt
"compatibility" with symbol versioning too.
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List [email protected]
Re: POPT 2.0: version stamping in includes
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
reasonable.
> Hmmm ... I suspect I'll be lazy and do nothing until I'm forced.
Spoken like a true engineer. ;-)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.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"
__
POPT Library http://rpm5.org
Developer Communication List [email protected]
Re: POPT 2.0: version stamping in includes
On Jun 18, 2010, at 8:13 PM, Michael Jennings wrote: > On Friday, 18 June 2010, at 14:01:05 (-0400), > Jeff Johnson wrote: > >> Should I go to the effort of a run-time "features" acquisition API? > > IMHO, no. Any time you add fluff, you get further away from the meat, > and there's room for error. The least error-prone approach is to > check for X when you use X, check for Y when you use Y, etc., or at > least check for the most recently-added of X, Y, and Z. But the > moment you start checking for symbol Q which is supposed to indicate > the presence of X but isn't actually X, gratuitous abstraction and > potential for mistakes are introduce for no (again, IMHO) gain. > 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. Hmmm ... I suspect I'll be lazy and do nothing until I'm forced. > Of course, in reality, whatever the documentation examples show as the > "right way to check for POPT 2.0" is precisely what will be > copied-and-pasted into code for the next half-century. But you know > this better than I. > Thanks for opinions. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: POPT 2.0: version stamping in includes
On Friday, 18 June 2010, at 14:01:05 (-0400), Jeff Johnson wrote: > Should I go to the effort of a run-time "features" acquisition API? IMHO, no. Any time you add fluff, you get further away from the meat, and there's room for error. The least error-prone approach is to check for X when you use X, check for Y when you use Y, etc., or at least check for the most recently-added of X, Y, and Z. But the moment you start checking for symbol Q which is supposed to indicate the presence of X but isn't actually X, gratuitous abstraction and potential for mistakes are introduce for no (again, IMHO) gain. Of course, in reality, whatever the documentation examples show as the "right way to check for POPT 2.0" is precisely what will be copied-and-pasted into code for the next half-century. But you know this better than I. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "A lot of times, men do things they don't want to do so the woman they're going out with will do things *they* don't want to do." -- Tim Allen __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: POPT 2.0: version stamping in includes
On Jun 18, 2010, at 1:45 PM, Michael Jennings wrote: > On Friday, 18 June 2010, at 10:52:22 (-0400), > Jeff Johnson wrote: > >> (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 > > I've always preferred this technique myself. Versioning macros and > such often fail to account for things like SVN snapshots or human > error. Always better to look for what you're actually trying to > *use*. > Should I go to the effort of a run-time "features" acquisition API? (aside) For a "toy" library like POPT, all of this is horrendous overkill engineering. OTOH, horrendous overkill engineering is _EXACTLY_ what has made both POPT/RPM successful. Less maintenance -> more usage. YMMV. But that's MHO on the matter. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: POPT 2.0: version stamping in includes
On Friday, 18 June 2010, at 10:52:22 (-0400), Jeff Johnson wrote: > (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 I've always preferred this technique myself. Versioning macros and such often fail to account for things like SVN snapshots or human error. Always better to look for what you're actually trying to *use*. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "A little learning is a dangerous thing; Drink deep, or taste not the Pierian spring: There shallow draughts intoxicate the brain, And drinking largely sobers us again." -- Alexander Pope, "An Essay on Criticism" __ POPT Library http://rpm5.org Developer Communication List [email protected]
