This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new blood


On Sat, Apr 30, 2005 at 06:56:59PM -0700, Brian Dessent wrote:
>Christopher Faylor wrote:
>
>> AFAICT, you'd need one cygwin app and one mingw app.  I don't know if the test suite
>
>For testing environment, wouldn't calling both getenv() and
>GetEnvironmentVariable() eliminate the need for a mingw helper?  That
>is, unless we want to explicitly test both cases where the child is a
>Cygwin program and native... which now that I think about it sounds like
>not a bad thing to want to test.

Yes.  That's what I was thinking.  I don't think it's likely that there
would be any problems with mingw childern, but...

The other really tricky part is setting up -X and non -X mounts.

>> can build mingw apps now.  Probably not.  Getting different command line options
>> to gcc might be tricky.
>
>Looking at winsup.exp, it seems that if we chose a naming convention
>(such as "*-mingw.c") for source files, it could add switches as
>necessary based on pattern match.

Good idea.

>>That's what I was thinking.  I think other tests do this.
>
>I'll see if I can modify what I have to exec itself.
>
>>The parent could also set SYSTEMROOT (and PATH) to something else.  In
>>the SYSTEMROOT case you have to make sure that the SYSTEMROOT isn't
>>being erroneously regenerated.  So you'd have to start the app with a
>>command line argument indicating what to expect and check SYSTEMROOT
>>against that.
>
>Yeah, I was thinking either that or have it write() its findings to
>stdout and have the parent read it through a pipe, and compare there.
>Doing it with argv is simpler though and eliminates the possibility of
>introducing extra complications because of the pipe.

I can see benefits either way.

>>This is a lot trickier than I thought it would be.  The number of
>>combinations involved in testing all of this is pretty high.
>
>I guess that's why thorough test harnesses tend to be rare on volunteer
>projects.

Absolutely.  But think how wonderful it would be if we had a thorough
test harness for cygwin.

FWIW, many years ago I used to run cygwin through PCTS and I sometimes
run some components through the test suite here:
http://posixtest.sourceforge.net/

But cygwin has some quirks all of its own which need to be documented.

Brian, if you want to take this on in any way, you will have my undying
gratitude.

Thanks for looking into this particular problem.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]