Running unit tests on Windows

[Jakob Eriksson]

The http://www.codeweavers.com/about/news/talks/wineconf2002/regression/Slide17....

talks about compiling on Windows with proprietary compilers.
Since I've seen on this list ideas about compiling with mingw on Windows
instead.
Shouldn't it be possible to cross-compile with mingw on Linux instead?
That way the samba share would also keep the .EXE files, and life would be
much simpler...

just a thought. what do you all think?

-- 
regards,
Jakob Eriksson

The wages of sin
  is debugging.
		  	-- Ron Jeffries

[Uwe Bonnes]

> > > > > "Jakob" == Jakob Eriksson <jakob(a)vmlinux.org> writes:

Jakob> The
    Jakob> http://www.codeweavers.com/about/news/talks/wineconf2002/regression/Slide17....

    Jakob> talks about compiling on Windows with proprietary compilers.
    Jakob> Since I've seen on this list ideas about compiling with mingw on
    Jakob> Windows instead.  Shouldn't it be possible to cross-compile with
    Jakob> mingw on Linux instead?  That way the samba share would also keep
    Jakob> the .EXE files, and life would be much simpler...

    Jakob> just a thought. what do you all think?

Yes, 

I prefer compiling the windows executable with mingw on linux too.

Bye

-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Vincent Béron]

Uwe Bonnes a écrit :
> > > > > > "Jakob" == Jakob Eriksson <jakob(a)vmlinux.org> writes:
>
> Jakob> The
>     Jakob> http://www.codeweavers.com/about/news/talks/wineconf2002/regression/Slide17....
>
> Jakob> talks about compiling on Windows with proprietary compilers.
>     Jakob> Since I've seen on this list ideas about compiling with mingw on
>     Jakob> Windows instead.  Shouldn't it be possible to cross-compile with
>     Jakob> mingw on Linux instead?  That way the samba share would also keep
>     Jakob> the .EXE files, and life would be much simpler...
>
> Jakob> just a thought. what do you all think?
>
> Yes,
>
> I prefer compiling the windows executable with mingw on linux too.

Cross-compile, or compile with mingw under Wine? The difference is the
nativity(?) of the compiler. Although i guess it wouldn't change much...
> Bye
>
> --
> Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. [phone] -------- Fax. [phone] ----------

[Jakob Eriksson]

On Thu, May 09, 2002 at 09:47:56PM +0200, Uwe Bonnes wrote:
> > > > > > "Jakob" == Jakob Eriksson <jakob(a)vmlinux.org> writes:
>
> Jakob> The
>     Jakob> http://www.codeweavers.com/about/news/talks/wineconf2002/regression/Slide17....
>
> Jakob> talks about compiling on Windows with proprietary compilers.
>     Jakob> Since I've seen on this list ideas about compiling with mingw on
>     Jakob> Windows instead.  Shouldn't it be possible to cross-compile with
>     Jakob> mingw on Linux instead?  That way the samba share would also keep
>     Jakob> the .EXE files, and life would be much simpler...
>
> Jakob> just a thought. what do you all think?
>
> Yes,
>
> I prefer compiling the windows executable with mingw on linux too.

How do you go about crosscompiling the tests?
I have managed to do "hello world" style programs with cross-mingw,
but to compile the Wine tests I don't know how to do...

When I try to compile a slightly modified
dlls/kernel/tests/file.c 

I get this:

jakov(a)black:/tmp> 
jakov(a)black:/tmp> i586-mingw32msvc-gcc file.c 
/usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/libmingw32.a(main.o)(.text+0x8f): undefined reference to `WinMain(a)16'


I assume there is something evil about the 16 bit API file.c is testing. *shrug*



(I guess somewhere in here the project of keeping mingw, ReactOS and
Wine headers in sync come into play... BTW I've noticed the ReactOS people
seem to feel a little ignored by Wine.)



-- 
regards,
Jakob Eriksson

The wages of sin
  is debugging.
		  	-- Ron Jeffries

[Uwe Bonnes]

> > > > > "Jakob" == Jakob Eriksson <jakob(a)vmlinux.org> writes:

Jakob> On Thu, May 09, 2002 at 09:47:56PM +0200, Uwe Bonnes wrote:

    >> I prefer compiling the windows executable with mingw on linux too.
    >> 

    Jakob> How do you go about crosscompiling the tests?  I have managed to
    Jakob> do "hello world" style programs with cross-mingw, but to compile
    Jakob> the Wine tests I don't know how to do...

I said I's "prefer". I haven't used the test suite yet. 
For problemetic things I still write normal C-Programs to crosscompile with
mingw and run with vmware...

    Jakob> When I try to compile a slightly modified
    Jakob> dlls/kernel/tests/file.c

    Jakob> I get this:

    Jakob> jakov(a)black:/tmp> jakov(a)black:/tmp> i586-mingw32msvc-gcc file.c
    Jakob> /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/libmingw32.a(main.o)(.text+0x8f):
    Jakob> undefined reference to `WinMain(a)16'

mingw is 32 bit and nothing else...

    Jakob> (I guess somewhere in here the project of keeping mingw, ReactOS
    Jakob> and Wine headers in sync come into play... BTW I've noticed the
    Jakob> ReactOS people seem to feel a little ignored by Wine.)

Bye

-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Steven Edwards]

> jakov(a)black:/tmp> 
> jakov(a)black:/tmp> i586-mingw32msvc-gcc file.c 
> /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mi
> ngw32msvc/lib/libmingw32.a(main.o)(.text+0x8f): undefined 
> reference to `WinMain(a)16'

There is no main statement in file.c 

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson

Breakthrough! Can now crosscompile unit tests!

[Jakob Eriksson]

On Thu, May 09, 2002 at 08:01:51PM -0400, Steven Edwards wrote:
> > jakov(a)black:/tmp> 
> > jakov(a)black:/tmp> i586-mingw32msvc-gcc file.c 
> > /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mi
> > ngw32msvc/lib/libmingw32.a(main.o)(.text+0x8f): undefined 
> > reference to `WinMain(a)16'
>
> There is no main statement in file.c

Ah, but of course! :-)    I'm happy now!

Now it works, at least for dlls/kernel/tests/file.c

If you compile with:

i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c


The magic is the defines of ok, todo_wine and START_TEST.

See this as proof of concept, I'm sure someone can make this
look better.

(If you have Debian 3.0, just "apt-get install mingw32-runtime mingw32".)


How do I make this happen automagically when doing "make tests"?


#ifndef REAL_EXE

#include "winbase.h"
#include "winerror.h"
#include "wine/test.h"

#else

#include <windows.h>
#include <stdio.h>
#define ok(val, msg) {if (!(val)) {printf ("%s\n", msg);} }
#define todo_wine
#define START_TEST main

#endif /* REAL_EXE */


#include <stdlib.h>
#include <time.h>


LPCSTR filename = "testfile.xxx";
LPCSTR sillytext =
"en larvig liten text dx \033 gx hej 84 hej 4484 ! \001\033 bla bl\na.. bla bla."
"1234 43 4kljf lf &%%%&&&&&& 34 4 34   3############# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&&&&&& 34 4 34   3############# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&&&&&& 34 4 34   3############# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&&&&&& 34 4 34   3############# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&&&&&& 34 4 34   3############# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&&&&&& 34 4 34   3############# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&&&&&& 34 4 34   3############# 33 3 3 3 # 3## 3"
"1234 43 4kljf lf &%%%&&&&&& 34 4 34   3############# 33 3 3 3 # 3## 3"
"sdlkfjasdlkfj a dslkj adsklf  \n  \nasdklf askldfa sdlkf \nsadklf asdklf asdf ";


static void test__lcreat( void )
{
    HFILE filehandle;
    char buffer[10000];
    WIN32_FIND_DATAA search_results;

    filehandle = _lcreat( filename, 0 );
    ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on directory?" );

    ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite complains." );

    ok( 0 == _llseek( filehandle, 0, FILE_BEGIN ), "_llseek complains." );

    ok( _hread( filehandle, buffer, strlen( sillytext ) ) ==  strlen( sillytext ), "erratic _hread return value." );

    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    ok( INVALID_HANDLE_VALUE != FindFirstFileA( filename, &search_results ), "should be able to find file" );

    ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );

    filehandle = _lcreat( filename, 1 );
    ok( HFILE_ERROR != filehandle, "couldn't create file!?" );

    ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite shouldn't be able to write never the less." );

    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    ok( INVALID_HANDLE_VALUE != FindFirstFileA( filename, &search_results ), "should be able to find file" );

    ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );


    filehandle = _lcreat( filename, 2 );
    ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on directory?" );

    ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite complains." );

    ok( 0 == _llseek( filehandle, 0, FILE_BEGIN ), "_llseek complains." );

    ok( _hread( filehandle, buffer, strlen( sillytext ) ) ==  strlen( sillytext ), "erratic _hread return value." );

    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    todo_wine
    {
        ok( INVALID_HANDLE_VALUE == FindFirstFileA( filename, &search_results ), "should NOT be able to find file" );
    }

    ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );
    
    filehandle = _lcreat( filename, 4 ); /* SYSTEM file */

    ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on directory?" );

    ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite complains." );

    ok( 0 == _llseek( filehandle, 0, FILE_BEGIN ), "_llseek complains." );

    ok( _hread( filehandle, buffer, strlen( sillytext ) ) ==  strlen( sillytext ), "erratic _hread return value." );

    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    todo_wine
    {
        ok( INVALID_HANDLE_VALUE == FindFirstFileA( filename, &search_results ), "should NOT be able to find file" );
    }

    ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );
}


void test__llseek( void )
{
    INT i;
    HFILE filehandle;
    char buffer[1];
    long bytes_read;

    filehandle = _lcreat( filename, 0 );

    ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on directory?" );
    for (i = 0; i < 400; i++)
    {
        ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite complains." );
    }
    ok( HFILE_ERROR != _llseek( filehandle, 400 * strlen( sillytext ), FILE_CURRENT ), "should be able to seek" );
    ok( HFILE_ERROR != _llseek( filehandle, 27 + 35 * strlen( sillytext ), FILE_BEGIN ), "should be able to seek" );

    bytes_read = _hread( filehandle, buffer, 1);
    ok( 1 == bytes_read, "file read size error." );
    ok( buffer[0] == sillytext[27], "_llseek error. It got lost seeking..." );
    ok( HFILE_ERROR != _llseek( filehandle, -400 * strlen( sillytext ), FILE_END ), "should be able to seek" );

    bytes_read = _hread( filehandle, buffer, 1);
    ok( 1 == bytes_read, "file read size error." );
    ok( buffer[0] == sillytext[0], "_llseek error. It got lost seeking..." );
    ok( HFILE_ERROR != _llseek( filehandle, 1000000, FILE_END ), "should be able to seek past file. Poor, poor Windows programmers." );
    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );
}


static void test__llopen( void )
{
    HFILE filehandle;
    UINT bytes_read;
    char buffer[10000];
    
    filehandle = _lcreat( filename, 0 );
    ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on directory?" );
    ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite complains." );
    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    filehandle = _lopen( filename, OF_READ );
    ok( HFILE_ERROR == _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite shouldn't be able to write!" );
    bytes_read = _hread( filehandle, buffer, strlen( sillytext ) );
    ok( strlen( sillytext )  == bytes_read, "file read size error." );
    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );
    
    filehandle = _lopen( filename, OF_READWRITE );
    bytes_read = _hread( filehandle, buffer, 2 * strlen( sillytext ) );
    ok( strlen( sillytext )  == bytes_read, "file read size error." );
    ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite should write just fine." );
    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    filehandle = _lopen( filename, OF_WRITE );
    ok( HFILE_ERROR == _hread( filehandle, buffer, 1 ), "you should only be able to write this file..." );
    ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite should write just fine." );
    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    ok( DeleteFileA( filename ) != 0, "DeleteFileA complains." );
    /* TODO - add tests for the SHARE modes  -  use two processes to pull this one off */
}


static void test__lread( void )
{
    HFILE filehandle;
    char buffer[10000];
    long bytes_read;
    UINT bytes_wanted;
    UINT i;

    filehandle = _lcreat( filename, 0 );
    ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on directory?" );

    ok( HFILE_ERROR != _hwrite( filehandle, sillytext, strlen( sillytext ) ), "_hwrite complains." );

    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    filehandle = _lopen( filename, OF_READ );

    ok( HFILE_ERROR != filehandle, "couldn't open file again?");
    
    bytes_read = _lread( filehandle, buffer, 2 * strlen( sillytext ) );
    
    ok( strlen( sillytext ) == bytes_read, "file read size error." );

    for (bytes_wanted = 0; bytes_wanted < strlen( sillytext ); bytes_wanted++)
    {
        ok( 0 == _llseek( filehandle, 0, FILE_BEGIN ), "_llseek complains." );
        ok( _lread( filehandle, buffer, bytes_wanted ) == bytes_wanted, "erratic _hread return value." );
        for (i = 0; i < bytes_wanted; i++)
        {
            ok( buffer[i] == sillytext[i], "that's not what's written." );
        }
    }

    ok( HFILE_ERROR != _lclose( filehandle ), "_lclose complains." );

    ok( DeleteFileA( filename ) != 0, "DeleteFile complains." );
}


static void test__lwrite( void )
{
    HFILE filehandle;
    char buffer[10000];
    long bytes_read;
    UINT bytes_written;
    UINT blocks;
    UINT i;
    char *contents;
    HLOCAL memory_object;
    char checksum[1];

    filehandle = _lcreat( filename, 0 );
    ok( HFILE_ERROR != filehandle, "couldn't create file. Wrong permissions on directory?" );

    ok( HFILE_ERROR != _lwrite( filehandle, "", 0 ), "_hwrite complains." );

    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    filehandle = _lopen( filename, OF_READ );
    
    bytes_read = _hread( filehandle, buffer, 1);

    ok( 0 == bytes_read, "file read size error." );

    ok( HFILE_ERROR != _lclose(filehandle), "_lclose complains." );

    filehandle = _lopen( filename, OF_READWRITE );

    bytes_written = 0;
    checksum[0] = '\0';
    srand( (unsigned)time( NULL ) );
    for (blocks = 0; blocks < 100; blocks++)
    {
        for (i = 0; i < sizeof( buffer ); i++)
        {
            buffer[i] = rand(  );
            checksum[0] = checksum[0] + buffer[i];
        }
        ok( HFILE_ERROR != _lwrite( filehandle, buffer, sizeof( buffer ) ), "_hwrite complains." );
        bytes_written = bytes_written + sizeof( buffer );
    }

    ok( HFILE_ERROR != _lwrite( filehandle, checksum, 1 ), "_hwrite complains." );
    bytes_written++;

    ok( HFILE_ERROR != _lclose( filehandle ), "_lclose complains." );

    memory_object = LocalAlloc( LPTR, bytes_written );

    ok( 0 != memory_object, "LocalAlloc fails. (Could be out of memory.)" );

    contents = LocalLock( memory_object );

    filehandle = _lopen( filename, OF_READ );

    contents = LocalLock( memory_object );

    ok( NULL != contents, "LocalLock whines." );

    ok( bytes_written == _hread( filehandle, contents, bytes_written), "read length differ from write length." );

    checksum[0] = '\0';
    i = 0;
    do
    {
        checksum[0] = checksum[0] + contents[i];
        i++;
    }
    while (i < bytes_written - 1);

    ok( checksum[0] == contents[i], "stored checksum differ from computed checksum." );
    
    ok( HFILE_ERROR != _lclose( filehandle ), "_lclose complains." );

    ok( DeleteFileA( filename ) != 0, "DeleteFile complains." );
    /* TODO - add tests for the SHARE modes  -  use two processes to pull this one off */
}


START_TEST(file)
{
    test__lcreat(  );
    test__llseek(  );
    test__llopen(  );
    test__lread(  );
    test__lwrite(  );
}

Breakthrough! Can now crosscompile unit tests!

[Steven Edwards]

--- Jakob Eriksson <jakob(a)vmlinux.org> wrote:
> On Thu, May 09, 2002 at 08:01:51PM -0400, Steven
> Edwards wrote:
> > > jakov(a)black:/tmp> 
> > > jakov(a)black:/tmp> i586-mingw32msvc-gcc file.c

/usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mi
> > > ngw32msvc/lib/libmingw32.a(main.o)(.text+0x8f):
> > > undefined 
> > > reference to `WinMain(a)16'
> >
> > There is no main statement in file.c
>
> Ah, but of course! :-)    I'm happy now!
>
> Now it works, at least for dlls/kernel/tests/file.c
>
> If you compile with:
>
> i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c

If you have to do a #ifdef for the unit tests do the
generic _WINDOWS as this covers both the mingw and the
MSV_VC port. I dont know if this will give you trouble
when you go to cross compile wine/tools that have
#ifdef _WINDOWS but I use it on my mingw port.


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com

Breakthrough! Can now crosscompile unit tests!

[Uwe Bonnes]

> > > > > "Steven" == Steven Edwards <steven_ed4153(a)yahoo.com> writes:

Steven> If you have to do a #ifdef for the unit tests do the generic
    Steven> _WINDOWS as this covers both the mingw and the MSV_VC port. I
    Steven> dont know if this will give you trouble when you go to cross
    Steven> compile wine/tools that have #ifdef _WINDOWS but I use it on my
    Steven> mingw port.

Retinking my last mail and reading Steven's mail, wouldn't be __WIN32__ and
__WINE__ be the better choices to destinguish.

Bye
-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

Breakthrough! Can now crosscompile unit tests!

[Jakob Eriksson]

On Fri, May 10, 2002 at 04:21:05PM +0200, Uwe Bonnes wrote:
> > > > > > "Steven" == Steven Edwards <steven_ed4153(a)yahoo.com> writes:
>
> Steven> If you have to do a #ifdef for the unit tests do the generic
>     Steven> _WINDOWS as this covers both the mingw and the MSV_VC port. I
>     Steven> dont know if this will give you trouble when you go to cross
>     Steven> compile wine/tools that have #ifdef _WINDOWS but I use it on my
>     Steven> mingw port.
>
> Retinking my last mail and reading Steven's mail, wouldn't be __WIN32__ and
> __WINE__ be the better choices to destinguish.

You mean something like?

#ifdef __WINE__
#include <unit.h>
#else
#define bla bla
#endif




-- 
regards,
Jakob Eriksson

The wages of sin
  is debugging.
		  	-- Ron Jeffries

Breakthrough! Can now crosscompile unit tests!

[Jakob Eriksson]

On Fri, May 10, 2002 at 06:51:40AM -0700, Steven Edwards wrote:
> > Ah, but of course! :-)    I'm happy now!
> >
> > Now it works, at least for dlls/kernel/tests/file.c
> >
> > If you compile with:
> >
> > i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c
>
> If you have to do a #ifdef for the unit tests do the
> generic _WINDOWS as this covers both the mingw and the
> MSV_VC port. I dont know if this will give you trouble
> when you go to cross compile wine/tools that have
> #ifdef _WINDOWS but I use it on my mingw port.

I can now manually compile unit tests with

"i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c"

What I want is for the Wine configure to detect that mingw32
is present, then modify Makefiles so that when "make tests"
is run, EXE-files are modified.
I also don't want to do #ifdef REAL_EXE or whatever in every
c-file, I want all that to happen automagically in wine/test.h !
I want the configure script to take care of all that and always
compile unit tests twice, once for linux target, once for Windows
target. (EXE)

Then a .BAT file could easily be created that runs all the EXEs.

Bang, native unit testing in a box!


Challenge: I have very little clue about how Wines configure and
Makefiles work. Who does? Who should I bug with questions?


-- 
regards,
Jakob Eriksson

The wages of sin
  is debugging.
		  	-- Ron Jeffries

Breakthrough! Can now crosscompile unit tests!

[Steven Edwards]

> What I want is for the Wine configure to detect that
> mingw32
> is present, then modify Makefiles so that when "make
> tests"
> is run, EXE-files are modified.
> I also don't want to do #ifdef REAL_EXE or whatever
> in every
> c-file, I want all that to happen automagically in
> wine/test.h !
> I want the configure script to take care of all that
> and always
> compile unit tests twice, once for linux target,
> once for Windows
> target. (EXE)

You might be able to do ./configure --host=mingw
--target=mingw --target=mingw under your cross system.
Then in your configure script you can have a check
that does something like this

if
case in host os = *mingw*
Blah
fi

Where Blah is the change you need. I'm not very good
at programming and even worse at fixing configure
script/makefile bugs so I dont know what all you need
to do. Take a look at the recent patch A.J. submitted
that fixed my dlltool/wrap dlopen issues on
cygwin/mingw.
> Makefiles
> Alexandre is the one who know all about all, when ever
> I've had a makefile problem he has been very helpful.

Steven

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com

Breakthrough! Can now crosscompile unit tests!

[Alexandre Julliard]

Jakob Eriksson <jakob(a)vmlinux.org> writes:
> What I want is for the Wine configure to detect that mingw32
> is present, then modify Makefiles so that when "make tests"
> is run, EXE-files are modified.
> I also don't want to do #ifdef REAL_EXE or whatever in every
> c-file, I want all that to happen automagically in wine/test.h !
> I want the configure script to take care of all that and always
> compile unit tests twice, once for linux target, once for Windows
> target. (EXE)

OK I have hacked the makefiles to make cross-compilation
possible. It's a bit tricky because some parts of Wine need to be
compiled twice, since they are used both at compile-time and at
run-time. The way to do it is:

- create 3 empty directories: wine-src, wine-gcc, wine-mingw

- put the full source in wine-src, making sure you don't have any
  binaries in there

- in wine-gcc, do:
     ../wine-src/configure
     make depend
     make tools

- then in wine-mingw do:
     ../wine-src/configure --host=i586-mingw32msvc --with-wine-tools=../wine-gcc
     make depend
     make

This should build a full cross-compiled Wine. Of course most of it
doesn't actually compile at this point, but fixing that is left as an
exercise for the reader...

-- 
Alexandre Julliard
julliard(a)winehq.com

Breakthrough! Can now crosscompile unit tests!

[Jakob Eriksson]

On Sat, May 11, 2002 at 08:18:49PM -0700, Alexandre Julliard wrote:
> Jakob Eriksson <jakob(a)vmlinux.org> writes:
> > What I want is for the Wine configure to detect that mingw32
> > is present, then modify Makefiles so that when "make tests"
> > is run, EXE-files are modified.
> > I also don't want to do #ifdef REAL_EXE or whatever in every
> > c-file, I want all that to happen automagically in wine/test.h !
> > I want the configure script to take care of all that and always
> > compile unit tests twice, once for linux target, once for Windows
> > target. (EXE)
>
> OK I have hacked the makefiles to make cross-compilation
> possible. It's a bit tricky because some parts of Wine need to be
> compiled twice, since they are used both at compile-time and at
> run-time. The way to do it is:
>
> - create 3 empty directories: wine-src, wine-gcc, wine-mingw
>
> - put the full source in wine-src, making sure you don't have any
>   binaries in there
>
> - in wine-gcc, do:
>      ../wine-src/configure
>      make depend
>      make tools
>
> - then in wine-mingw do:
>      ../wine-src/configure --host=i586-mingw32msvc --with-wine-tools=../wine-gcc
>      make depend
>      make
>
> This should build a full cross-compiled Wine. Of course most of it
> doesn't actually compile at this point, but fixing that is left as an
> exercise for the reader...

Cool! :-)
This is looking better and better.

I'll try this and then come back to this list;
with whatever further unit testing progress I come up with.

I'll take it that some parts of Wine never will crosscompile
right? Makes no sense to port the kernel parts of Wine to Win32,
right? It would be like Linux ported to Linux. (I _know_ that exists...)



-- 
regards,
Jakob Eriksson

The wages of sin
  is debugging.
		  	-- Ron Jeffries

Breakthrough! Can now crosscompile unit tests!

[Jakob Eriksson]

On Sat, May 11, 2002 at 08:18:49PM -0700, Alexandre Julliard wrote:
> OK I have hacked the makefiles to make cross-compilation
> possible. It's a bit tricky because some parts of Wine need to be
> compiled twice, since they are used both at compile-time and at
> run-time. The way to do it is:
>
> - create 3 empty directories: wine-src, wine-gcc, wine-mingw
>
> - put the full source in wine-src, making sure you don't have any
>   binaries in there
>
> - in wine-gcc, do:
>      ../wine-src/configure
>      make depend
>      make tools
>
> - then in wine-mingw do:
>      ../wine-src/configure --host=i586-mingw32msvc --with-wine-tools=../wine-gcc
>      make depend
>      make
>
> This should build a full cross-compiled Wine. Of course most of it
> doesn't actually compile at this point, but fixing that is left as an
> exercise for the reader...

I couldn't make any of the unit tests compile...
but that's ok. Stand by for my master plan! :-)

-- 
regards,
Jakob Eriksson

The wages of sin
  is debugging.
		  	-- Ron Jeffries

Breakthrough! Can now crosscompile unit tests!

[Steven Edwards]

> I couldn't make any of the unit tests compile...
> but that's ok. Stand by for my master plan! :-)

With the latest patch I can compile a blank dll but
not a real one. Ntdll and libwine do not compile right
and they have the exports needed for every other
wine/dll, I will be submitting a bug report for them.

Also Alexandre, wrc compiled resources can be rebuilt
using windress so I will change the bug in bugzilla.
All that is needed now is a fix for the build system
when using mingw/cygwin to pass the wrc compiled
resources to windress then link.

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Breakthrough! Can now crosscompile unit tests!

[Alexandre Julliard]

Steven Edwards <steven_ed4153(a)yahoo.com> writes:
> Also Alexandre, wrc compiled resources can be rebuilt
> using windress so I will change the bug in bugzilla.
> All that is needed now is a fix for the build system
> when using mingw/cygwin to pass the wrc compiled
> resources to windress then link.

This should be fixed by my latest patch too. At least it seems to work
for me when cross-compiling, I have sucessfully built winemine.exe
with mingw (you need to remove ntdll and libwine from the link to make
it work, I'll try to fix that shortly).

-- 
Alexandre Julliard
julliard(a)winehq.com

Breakthrough! Can now crosscompile unit tests!

[Steven Edwards]

> This should be fixed by my latest patch too. At least it 
> seems to work for me when cross-compiling, I have sucessfully 
> built winemine.exe with mingw (you need to remove ntdll and 
> libwine from the link to make it work, I'll try to fix that shortly).

Kickass. I just built winemine with no problems. Mingw doesn't come with
a 
ntdll.a import lib so if the dll does really require something from
ntdll 
we will still need to build the import lib from the ntdll def right?

Also what about libwine? Do the Wine/dlls require it or would this be
part of 
dll speration? 

I don't know where they are at in the wine tree as I havent had time to
look but
for the ReactOS port we moved the wine debugging interfaces (FIXME,
TRACE, WARN)
to our ntdll although I don't know if it worked or not. Lacking
windowing we 
were not able to really test much of our port. 

I will try to do some more patches today or tommrow for a few minor
things. 

Thanks Again
Steven

Breakthrough! Can now crosscompile unit tests!

[Uwe Bonnes]

> > > > > "Jakob" == Jakob Eriksson <jakob(a)vmlinux.org> writes:

Jakob> On Thu, May 09, 2002 at 08:01:51PM -0400, Steven Edwards wrote:


    Jakob> Ah, but of course! :-) I'm happy now!

    Jakob> Now it works, at least for dlls/kernel/tests/file.c

    Jakob> If you compile with:

    Jakob> i586-mingw32msvc-gcc -o FILE.EXE -DREAL_EXE file.c


    Jakob> The magic is the defines of ok, todo_wine and START_TEST.

    Jakob> See this as proof of concept, I'm sure someone can make this look
    Jakob> better.

    Jakob> (If you have Debian 3.0, just "apt-get install mingw32-runtime
    Jakob> mingw32".)


    Jakob> How do I make this happen automagically when doing "make tests"?


You can test for __MINGW32__, __CYGWIN__ or __linux in your source:
#include <stdio.h>

int main(void)
{
  #ifdef __linux
  printf("compiled on linux\n");
  #endif
  #ifdef __MINGW32__
  printf("compiled with mingw\n");
  #endif
  return 0;
}
> gcc test.c
> ./a.out
> compiled on linux
> i386-mingw32msvc-gcc test.c
> wine a.exe
> compiled with mingw

Something like "make GCC=i586-mingw32msvc-gcc" (not sure about the syntax)
exchanges gcc against i586-mingw32msvc-gcc in well written Makefiles.

Are there any recent mingw rpm packages for linux?

Bye
-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Steven Edwards]

Jakob> (I guess somewhere in here the project of keeping mingw,
ReactOS
    Jakob> and Wine headers in sync come into play... BTW I've noticed
the
    Jakob> ReactOS people seem to feel a little ignored by Wine.)

My statement about the headers was a little to off cuff. The wine
project has been very helpful to me with my work on the wine dlls for
Mingw/ReactOS and I don't expect them to do any more for us then for any
other project. The issue of the headers is still something that needs to
be worked out and at the time I and Jason didn't think it received
enough attention. ATM though I am more interested in build the needed
dlls for a win32 subsystem on mingw now that ros can almost self-host. 

Yes I would like to see more wine "developers" interested in the ReactOS
mabey to help us get the windowing going but I don't want to drain
resources away from the wine project.

Sorry about the confusion
Thanks
Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson