pcp
[Top] [All Lists]

Re: More cleverer QA config needed? (was Re: [pcp] NSS/NSPR Testing Stat

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: More cleverer QA config needed? (was Re: [pcp] NSS/NSPR Testing Status)
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Fri, 30 Nov 2012 11:37:51 -0500
Cc: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, pcp@xxxxxxxxxxx
In-reply-to: <1855860738.36149046.1354263511386.JavaMail.root@xxxxxxxxxx>
References: <1855860738.36149046.1354263511386.JavaMail.root@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
On 11/30/2012 03:18 AM, Nathan Scott wrote:
----- Original Message -----
...
So, approach used so far is to add the sort of tests we have now
(PCP version based) as an initial "will this compile at all" check,
then a subsequent "dynamic" check is done via a call into a libpcp
routine that was added at the time of the initial feature commit.

There's pros and cons.  NSS doesn't actually have a routine like
this and we'd have to add something.  Need to think further on the
best option I think - maybe adding in a feature-test interface to
libpcp (analogous to sysconf(3), but less int-based) and also a
helper tool (something like getconf(1), for QA)?

Another option would be to use the pkg-config tool I guess.  Or we
continue on the query-interface-per-feature path, which works too.
Attached patch is an initial pass (untested) at approach #1 for your
consideration & amusement.  I came across the existing pmconfig(1) &
made this fit into that tool, with similar APIs.

Thoughts?

I like the idea of being able to query the library regarding its features/capabilities. This would certainly be useful for testing and would likely be useful for applications using the library.

Dave

<Prev in Thread] Current Thread [Next in Thread>