On November 28, 2002 04:23 am, Martin Wilck wrote: I've addressed both of these on the web page :)
> I can't follow you here. You seem to have been porting Applications > using Unix-Style Makefiles. I'd guess the vast majority of Applications > comes with Windows VC++ "project files" (.dsp) and "workspaces" (.dsw). >From the page: "Fortunately, most OSS applications have a build system based around the MinGW tool chain. Sometimes they have alternative build systems for the Borland and/or Microsoft tools, but more often than not they have to support the MinGW tools out of necessity. I will cover this class of applications for the rest of this section." I should have been more clear: this message address this class of apps. The closed source ones have a VC++ build system, as you say, and are covered by winemaker. Not the focus of my efforts, though. > In any case, IMO this is what's winemaker is all about. Your idea of > introducing compatibility tools is nice but somewhat limited in scope. > What we really need is a much more intelligent winemaker. >From the page: "Before I begin, I think I need to explain why we have to treat these applications any differently. Why don't we just run winemaker, and get it over with? The reason is quite simple: people are attached to their build process, and for good reason. If we are to have our modifications included in their tree, we can not simply submit a new build system. Such a patch would never be accepted. Needless to say, having these modifications included in their build process is important." If we are to just generate a parallel build system, we'd be wasting out time. We have to make it simple so we have a chance of the app maintainers doing the porting themselves. There are thousand of apps, all we can do is port a few. But if we want them to recognize Wine as a platform, and port to it, we can not expect them to simply accept a parallel set of makefiles which are just a bit different from what they have. -- Dimi.
