Re: POPT 2.0: version stamping in includes

2010-06-18 Thread Michael Jennings
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. MacO

Re: POPT 2.0: version stamping in includes

2010-06-18 Thread Jeff Johnson
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 nee

Re: POPT 2.0: version stamping in includes

2010-06-18 Thread Michael Jennings
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 li

Re: POPT 2.0: version stamping in includes

2010-06-18 Thread Jeff Johnson
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 e

Re: POPT 2.0: version stamping in includes

2010-06-18 Thread Michael Jennings
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

Re: POPT 2.0: version stamping in includes

2010-06-18 Thread Jeff Johnson
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

Re: POPT 2.0: version stamping in includes

2010-06-18 Thread Michael Jennings
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) > ...

POPT 2.0: version stamping in includes

2010-06-18 Thread Jeff Johnson
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.