Re: [P4W-posixdev] Testsuite

[Ronald Landheer-C. <ro...@la...>]

On Fri, 28 Feb 2003, Earnie Boyd wrote:
> Ronald Landheer-Cieslak wrote:
> > We've had a couple of interesting discussions so far *and* we've seen a 
> > proof of concept for the Cygwin cohabitation, so I propose the next thing 
> > to do is start the groundworks for a testsuite - just a few basic tests 
> > (such as the one needed for the proof of concept) in the form of scripts 
> > and C files, so we can easily test our stuff on different boxes (mine, 
> > yours, etc.) and expect the same results.
> > 
> > I would also like to start lobbying for Cygwin's testsuite to become 
> > available outside of Cygwin's sources - which would make it much easier 
> > for volunteers to test for regressions, and which would allow us to use 
> > their testsuite and merge it with ours :)
> The eXtreme Programming Experience model loves you. ;) 
Ehm.. [blush] ;)

> Remember that the two dll's of your test need two totally different
> builds of the dll.
>   Tests for cohabitation with Cygwin proper need to be included as well.
.. which is not a facilitating factor, but I wholly agree.

For the cohabitation tests: does MSYS leave any system-wide traces (as
Cygwin1.dll does in the registry?) I.e., I would like to be able to find
out (in a heartbeat)  where Cygwin and MSYS live (if they live at all) so
I can feed their sh a script or two from an sh linked to p4w-POSIX (a
script that should, of course, run something under the p4w-POSIX thingy).
I.e.: * sh for p4w-posix launches sh for Cygwin * sh for Cygwin launches
sh for p4w-POSIX * sh for Cygwin launches sh for MSYS (expected crash)
  (should we test this?)
* sh for p4w-posix launches sh for MSYS
* sh for MSYS launches sh for p4w-POSIX
* sh for MSYS launcges sh for Cygwin (expected crash)
  (should we test this?)

this scheme would prove that:
* MSYS apps can launch p4w apps;
* Cygwin apps can launch p4w apps
* p4w apps can launch MSYS apps and Cygwin apps

As p4w is technically (at least for the time being) just another version 
of Cygwin, we don't need two p4w DLLs to have one run the other and vice 
versa..

> What are you waiting on, get started. ;)  I agree that a separate test 
> suite would be handy.  Then those interested in helping other than 
> coding could report regressions easily.
My thoughts exactly - that why I think it would be a good idea for both 
MSYS and Cygwin as well :)

> Perhaps autotest (an autoconf subproject) would be worth using. 
I don't know that project yet - I'll have a look at it

> It doesn't require the complexities of dejagnu.
Good - I never did get started on using dejagnu, mostly because it's 
over-complex.

> I also think that we need to break the proposed testsuite into various
> parts.  Something like
> 
> testsuite/
>            cohabitation
>            kernel
>            misc
>            runtime
>            text-binary
> 
> We may break down even further say under kernel we would have basic, 
> threads, interprocess, etc.
yes.

> The testsuite should be parented in the p4wposix top level tree, do you 
> agree?
yes & no. As long as we use Newlib, and most of Cygwin, we should use 
their testsuites as well (and possibly deliver them as part of the 
separate(d) testsuite package). I am not in favour of moving their sources 
around in our source tree - at all - because it would make synchronising 
our CVS's (much) harder than needed.
I *am* in favour of symlinking their testcases into the build dir and 
taking it off from there, effectively pretending the sources all come from 
the same place. A well-placed call to symlink-tree will do that. 
(something like
1. cd winsup
2. symlink-tree $srcdir/../../winsup/testsuite
3. cd ../newlib
4. symlink-tree $srcdir/../../newlib/testsuite
5. cd ..
6. symlink-tree $srcdir
7. mkdir \=build
8. cd \=build
9. ../configure && make all check
as the check target, probably using an extra stamp file to not do it 
twice).

Note: *something like* that - I have done things *like* this when I needed 
to, but I haven't tried this one yet

rlc