On September 24, 2003 03:47 am, Pavel Roskin wrote:
I have looked at winegcc source and it seems it will greatly improve portability. I think it's a good idea to switch to winegcc first.
Thoose who compile large projects with Wine are not likely to abandon the Windows version, so it's helpful to minimize differences in the code for different platforms. If we consider Wine programs as test examples, they should compile for Windows cleanly and use winegcc when compiled in Wine if we are to recommend winegcc for outside projects.
Yes, this was my primary motivation for developing winegcc. A build system is a nontrivial thing (sometimes quite complicated/cryptic), and maintaining two of them is just too much to ask. Even if someone invests the time to develop a Wine specific one when porting an app to Wine, it will most likely become obsolete in no time.
To test the winegcc concept, I've already ported a number of app (which had a MinGW build system before) such as wxWindows, visual-mingw, putty, etc. They indeed worked with minimal changes to their Makefiles. The changes that were done were for the sake of portability and actually improved their build process in the MinGW case. So it's now possible to build for Wine and MinGW from the same sources & build systems. We are still lacking DLL generation support though. For more information on this effort, check this out: http://www.winehq.org/site/winelib
I just don't like defining __WINE__ in wrc when not compiling for Wine. But it's not a big deal. I'm attaching a patch that shows what I mean. Apply it if you like it.
I'm not sure why we had those defines in there. In general, we try to avoid defines like the plague in the Wine tree, so your patch is much appreciated. It seems that was some code the initial developers had in there for their own testing, and somehow it slipped in. Please send your patch to wine-patches for inclusion in the tree.