RE: winebuild & (name, heap, init)

[Patrik Stridvall]

> > > But beyond that, we can *today* compile Wine with Mingw as PE. So
> > > what we need is a checkspec make target which would run
>
> your script,
> > > compile Wine as PE, extract what needs extracting from there, and
> > > compare results. This does not need to happen all the time, only
> > > from time to time by some people that (1) have Mingw installed,
> > > and (2) care to do it :).
> >
> > True. However I still a little worried about the "stabillity"
> > of the solution.
>
> Why? This is as good of a verification method (no, even better) than
> what we have today.

Sure, but I have written the Perl code I know how ad hoc it is.
It works under reasonable assumptions however beyond that...

But I'm not really against it, I'm just pointing out
potential problems...

winebuild & (name, heap, init)

[Dimitrie O. Paun]

On September 11, 2002 11:33 am, Patrik Stridvall wrote:
> Sure, but I have written the Perl code I know how ad hoc it is.
> It works under reasonable assumptions however beyond that...

But we don't *want* Wine's sources to look beyond reasonable.
I see no problem. Even better, if this helps us detect unreasonable
looking sources...

winebuild & (name, heap, init)

[Steven Edwards]

/me jumps in on this thread for a sec

--- Patrik Stridvall  wrote:
> > > > But beyond that, we can *today* compile Wine with Mingw as PE. So
> > > > what we need is a checkspec make target which would run
> >
> > your script,
> > > > compile Wine as PE, extract what needs extracting from there, and
> > > > compare results. This does not need to happen all the time, only
> > > > from time to time by some people that (1) have Mingw installed,
> > > > and (2) care to do it :).
> > >
> > > True. However I still a little worried about the "stabillity"
> > > of the solution.
> >
> > Why? This is as good of a verification method (no, even better) than
> > what we have today.
>
> Sure, but I have written the Perl code I know how ad hoc it is.
> It works under reasonable assumptions however beyond that...
>
> But I'm not really against it, I'm just pointing out
> potential problems...

I thought the WINE tree and regression suite would try and move away from a perl dependancy?
How is all of this going to effect building on Windows/ReactOS with Mingw? I have had a bitch of a
time getting Mingw+MSYS+Perl working and would hate to see it become a bigger requirement. If
-mno-cygwin worked right I dont guess it would be as big of a deal because then we could still
build WINE-Mingw under cyg but atm some import is still hosing things up and forcing importation
of cygwin1.dll so the recommended setup is just Mingw+MSYS.

Note: even using perl on cygwin is still borked atm for the regression suite and I havent even
tried winapi_check. another option may be to look at active perl for windows but I really dont
like that idea.

Thanks
Steven

__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute

winebuild & (name, heap, init)

[Alexandre Julliard]

Steven Edwards  writes:
> I thought the WINE tree and regression suite would try and move away from a perl dependancy?
> How is all of this going to effect building on Windows/ReactOS with Mingw? I have had a bitch of a
> time getting Mingw+MSYS+Perl working and would hate to see it become a bigger requirement. If
> -mno-cygwin worked right I dont guess it would be as big of a deal because then we could still
> build WINE-Mingw under cyg but atm some import is still hosing things up and forcing importation
> of cygwin1.dll so the recommended setup is just Mingw+MSYS.

Yes, we should try to move away from the Perl requirement for
regression tests. It was considered OK to depend on it because the
framework itself was based on Perl, but now that all tests are done in
C anyway we should probably get rid of it. In any case Perl should
never be a requirement for building Wine itself.