new old winetests

[Dimitrie O. Paun]

On December 2, 2003 05:48 am, Ferenc Wagner wrote:
> "Dimitrie O. Paun" <dpaun at rogers.com> writes:
> >   -- the mkdir() issue is still not 100% solved. We currently have:
> > #ifndef _WIN32
> > #  define mkdir(d) mkdir (d, 0777)
> > #endif
> >      [...] Why don't we just link with msvcrt?
>
> "Dimitrie O. Paun" <dpaun at rogers.com> also wrote:
> > "Doctor, it hurts when I do that..." :))) I'd say, don't
> > do it.  Just use libc calls, don't link against msvcrt.
>
> That's why.  To preserve our sanity.  Maybe it's not worth it.

:))) I know there was a reason, but I can't quite remember
what the problem was. :)

> >      Or we can change the test to:
> > #if defined(__unix__) && !defined(__MSVCRT__)
> >      which should work with all: gcc/winegcc/mingw/msvc
>
> It may be the easier path.  But this strongly depends on
> Alexandre's verdict.  See the discussion on the other branch
> of this thread.

Well, unfortunately, the mkdir() bit is a ugly wart. I've run
into it in other projects (wxWindows comes to mind). If anyone
can figure out a solution that doesn't involve modifying the
app, let me know. Until then this should do.

> >   -- we use fatal() in remove_dir()
> >      Again, not a problem, but I'm wondering if we're not too strict.
>
> Sure, we are.  In the beginning, nothing useful happened
> after remove_dir(), so I just didn't care.  Moving send_file
> before this would be useful indeed.  Someone someday may
> create a real UI for this and handle it properly.

Until then, how about we replace the fatal() call to a
warning() call which does not exit?

> >   -- running ELF tests
> >      When we do so, we use a hardcoded path for wine
>
> Oh yes, that's for me who does not have wine in the path.
> We could just remove the path, I could add wine to my PATH,
> and that's it.

Well, let's do that then :)

> >   -- we're linking against ws2_32
> >      Is this DLL available on all versions of Windows we
> >      want to run on?
>
> As far I know
> <http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_st
>art_page_2.asp> yes. 

It's OK then. We need to depend on _something_ to send out
the results, this seems like a decent dependency.

>
> > I can't see any showstoppers
>
> Good to you. :)  What do you think about Alexandre's cross-
> configuring idea?

Well, it's a clean idea. The CROSSCC stuff that I've adopted
from the tests it's a bit of a hack, and I do not understand
why we have it in the first place. It's convenient, but a bit
ugly (and I guess it survives since it's so small). However,
as you pointed out, if we do use it for tests, why not for
winetests, it fits in the same category, it's convenient, and
we can use it almost as is (this is the only thing we do in
our Makefile):

winetests_cross.exe: $(CROSSOBJS:_so.res.cross.o=_pe.res.cross.o)
        $(CROSSCC) $^ -o $@ $(IMPORTS:%=-l%) $(LIBS)

So Alexandre, what say you? :) We'd really like to get this in
and move forward, there still so much work to do on this front.
Let's not lose momentum.

-- 
Dimi.