This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: new blood
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin-developers at cygwin dot com
- Date: Sat, 30 Apr 2005 18:56:59 -0700
- Subject: Re: new blood
- References: <20050429165613.GA14614@trixie.casa.cgf.cx> <4273651D.D377B13B@dessent.net> <20050430172622.GA4892@trixie.casa.cgf.cx> <4274203C.27741B@dessent.net> <20050501010041.GA21071@trixie.casa.cgf.cx>
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.
> 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.
> 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.
> 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.
Brian