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.