On Feb 10, 2008, at 1:46 AM, Dan Nicholson wrote:

> On Feb 9, 2008 5:29 AM, Jeff Johnson <n3npq@mac.com> wrote:
>>
>> On Feb 9, 2008, at 8:09 AM, Jeff Johnson wrote:
>>>
>>> Or fix the linkage.
>>>
>>
>> How about the attached patch instead? WORKSFORME.
>>
>> And I'm still shopping ideas for how to add "make check" to rpmio
>> intelligently.
>
> That seems fine. Also, you can put the C test programs in
> check_PROGRAMS and they'll only be built when `make check' is run.
> Right now, "tdir tfts tget tglob" are all built whether you want to
> run check or not.
>

Thanks. Ralf has already cleaned up my sloppiness.

After a bit of noodling, what I think I'm gonna do is swipe
a copy of pcregrep.c and rewrite to use Fopen() instead
of fopen(), etc, using other rpmio peculier structures
and coding style internally to pcregrep.c.

That basically means that I can also swipe the "make check"
tests (and framework) frpm pcregrep to bootstrap automated
rpmio testing as well.

So if you don't like/want similar to pcre-7.6 "make check" does in  
rpmio/*,
please suggest better alternatives or a different approach.

What will still need thought is the client <-> server aspects
of rpmio "make check".

Sure I can test for network connectivity and disable URI testing
if end-point URI's are not accessible. But

	disabling != testing

The better (what I've seen) approach is what neon does. The
neon test harness lives on both sides of client <-> server
localhost connection, basically a server is built and started
by "make check".

Doing similar in rpmio is likely more work/time than I have this
month, sigh. I'll get there eventually ...

73 de Jeff