Some more MSVC fixes

Patrik Stridvall ps at leissner.se
Wed Feb 6 13:51:38 CST 2002


> > Personally I think that the ultimate solution would be to
> > automatically generate the .dsp files from Makefile.in or otherwise.
> 
>    May not be easy but you are pretty good with perl so if anyone can
> pull it off it's you :-)

I don't think it is that difficult even for somebody less comfortable with
Perl. The problem is getting all the details right and that will take some
time, but allmost all details are quite easy, I think.

>    Once you have all the .dsp files, make a big .dsw file in the
> top-level directory that references all the other .dsp files. That way
> you can double-click on the .dsw, and then pick which dll you want to
> build, build them all at once, etc. I guess you already know 
> about them
> (and they are really simple to generate).

Yes, I have it that way right now. But I only have a .dsp for a of
few DLLs since doing it manually is quite boring.

It would be quite nice to have all non core DLL compiling and 
working and with winetest ported. Then you could just run winetest
through the debugger and be able to set breakpoint and step through
the code in Visual Studio in order to get all to tests to run properly. :-)
  
> > Hmm. Well, I gave the MS headers one more try and discovered
> > a few not so nice things.
> >
> > If you have a Wine specific include like below in a file:
> > #include "heap.h"
> > and this file heap.h in turn has a
> > #include "winbase.h"
> > it will include the Wine version of the file instead of the
> > MS version. This is probably because with "" files in the
> > same directory has priority IIRC.
> 
>    No, that's because we use '-I .', which is a questionable practice.
> Unfortunately I believe there is something that makes it hard to avoid
> in Wine's case. I cannot remember what though.

No, I don't think so. First of all -I. means current directory that is
the directory of the current .c file. I was refering to that the
#include "winbase.h" in file heap.h in wine/include perfered the 
winbase.h in wine/include rather than the MS variant. This is
propably because #include "" with MSC always chooses the include
from the same dir first rather the Microsoft dir that was EARLIER
in the -I path (or rather the MSC equivalent). In the .c file
#include "winbase.h" correctly included the MS variant.

I haven't tested if GNU C have the same behavior but it might.

> > > > Of course you could add the MS header for inclusion one
> > > > more time after the Wine headers, but where they
> > > > are under Windows are installation dependent and not
> > > > very portable. :-(
> > >
> > > Yeah, but that could be determined by configure.
> >
> > True.
> 
>    But you would have to run configure on Windows, no? Since configure
> is a shell script this means you need something like cygwin to compile
> the source :-/ Or did you mean to run configure on Unix to 
> generate just
> the right Makefiles for use on Windows?

I didn't nessisarily mean configure but rather a Perl script that
generates the .dsp files. Just install Perl and double click
on configure.pl and all the .dsp was generated. Then double click
on wine.dsw and you are ready to go.




More information about the wine-devel mailing list