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


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


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