Folks,
Anyone remembers why we need our own cpp implementation, instead of simply using cpp/gcc -E?
Anyone remembers why we need our own cpp implementation, instead of simply using cpp/gcc -E?
IIRC it was a standalone program that Bertho maintained (and used in lots of other contexts than wine) (but I don't remember which ones)
anyway, the tool has been incorporated into wine as it was some options must remain from those days :-)
A+
"Dimitrie O. Paun" dpaun@rogers.com writes:
Anyone remembers why we need our own cpp implementation, instead of simply using cpp/gcc -E?
I believe it was mostly issues with getting rid of C code in header files, though that is handled in the main parser now. Still, it's not guaranteed that the C preprocessor would handle non C code correctly.
On December 8, 2002 05:56 pm, Alexandre Julliard wrote:
I believe it was mostly issues with getting rid of C code in header files, though that is handled in the main parser now. Still, it's not guaranteed that the C preprocessor would handle non C code correctly.
Hmm, I don't know about that either -- windres certainly calls gcc -E, and it's working just fine. Anyway, I don't see a compelling reason to change the status quo, thanks for helping me clarify this issue.
On Sun, 8 Dec 2002, Dimitrie O. Paun wrote:
On December 8, 2002 05:56 pm, Alexandre Julliard wrote:
I believe it was mostly issues with getting rid of C code in header files, though that is handled in the main parser now. Still, it's not guaranteed that the C preprocessor would handle non C code correctly.
Hmm, I don't know about that either -- windres certainly calls gcc -E, and it's working just fine.
Projects compiled using MinGW and windres are not 'normal' Windows projects. In particular they don't prove that a project built using Visual C++ and rc is going to compile if you process the rc files using gcc -E.
Given the dominant position of Visual C++ on the Windows platform, compatibility with Visual C++ projects is the main point of Winelib. it is orders of magnitude more important than compatibility with windres and MinGW-based projects. Let's not forget the goal of Winelib: making it possible to recompile Windows applications to Unix, not making it possible to compile native Unix applications using the Windows API+MinGW. Better compatibility with MinGW is a means to that end, no more.
I don't know whether we still need the integrated preprocessor, but I think we should not be too hasty in removing it. It would be pretty bad to remove it just to discover a few months later that it was needed after all.
On December 9, 2002 04:45 pm, Francois Gouget wrote:
Let's not forget the goal of Winelib: making it possible to recompile Windows applications to Unix, not making it possible to compile native Unix applications using the Windows API+MinGW.
Not that I disagree with your points, but I think there is some confusion about MinGW. MinGW apps are NOT native Unix apps. They are native Windows app that just happen to use gcc instead of MSVC for the compiler.
Now, give that most OSS Windows app support MinGW, I think it's a very important segment we need to address (not to mention most like a lot easier to capture). Yeah, most commercial apps do use MSVC, but those app need internal forces for a port anyway, all we can do is make it easy for them. Most important in that area is probably .dsp support in winemaker, but this is a different ball of wax...
On Sun, 8 Dec 2002, Dimitrie O. Paun wrote: [...]
Hmm, I don't know about that either -- windres certainly calls gcc -E, and it's working just fine. Anyway, I don't see a compelling reason to change the status quo, thanks for helping me clarify this issue.
What we might do is change the way we compile rc files so that we use gcc -E rather than wpp and see if that causes problems. This would have to be done in Wine and in winemaker (especially in winemaker). That way if there are problems we would be more likely to discover them (though it might take a few months) and would still be able to easily switch back to using wpp if necessary.
On December 9, 2002 05:09 pm, Francois Gouget wrote:
What we might do is change the way we compile rc files so that we use gcc -E rather than wpp and see if that causes problems.
There is already a dummy --preprocessor option in wrc (for compatibility with windres). First step would be properly implement that one, to allow for external override of the preprocessor. Then we can experiment with it, see what we get (errors, speed penalties, etc.).
"Dimitrie O. Paun" dpaun@rogers.com writes:
There is already a dummy --preprocessor option in wrc (for compatibility with windres). First step would be properly implement that one, to allow for external override of the preprocessor. Then we can experiment with it, see what we get (errors, speed penalties, etc.).
Frankly, this ranks about as high on the priority list as the strcat optimizations in makedep. Are there really no more real problems to solve that we need to spend so much effort inventing new ones?
On December 9, 2002 06:33 pm, Alexandre Julliard wrote:
Frankly, this ranks about as high on the priority list as the strcat optimizations in makedep. Are there really no more real problems to solve that we need to spend so much effort inventing new ones?
You're obviously right Alexandre. I was just completing Francois thought here, it's not like I proposed it as a big problem that needs solving... :)
And don't worry, I have patches comming your way, I'm just waiting for the ones that I've already submitted to go in (the others in the queue are quite dependand on those). <g>
On Sun, 8 Dec 2002, Dimitrie O. Paun wrote:
Folks,
Anyone remembers why we need our own cpp implementation, instead of simply using cpp/gcc -E?
http://www.winehq.com/news/?view=36#Wine%27s%20resource%20compiler
Seems you argued against wrc having its own cpp implementation already back then. So the real reason why we now have wpp is probably because it was Bertho who implemented wrc and nobody else, and he wanted wrc to have an integrated preprocessor. No really compelling reasons were cited, but volunteers willing to do something themselves need no better reason. And I wouldn't mind keeping it, it's fast, easy to use, and guaranteed to work with Microsoft source code. wpp got factored out of wrc when I decided to use Bertho's preprocessor for widl too.
On December 8, 2002 05:58 pm, Ove Kaaven wrote:
http://www.winehq.com/news/?view=36#Wine%27s%20resource%20compiler
Thanks for the reference, nice summary! :)
Seems you argued against wrc having its own cpp implementation already back then.
Yeah, I remember arguing against it than, but I could not remember what were the pro/cons arguments, and if they still hold true. I do agree that Bertho had the right to do whatever he wanted, he was doing the work. In fact, I understand Bertho's motivation, it's just not sure to me that it makes sense in the Wine context.
Anyway, thanks again for helping me refresh my memory. Much appreciated! :)
-
Alexandre Julliard -
Dimitrie O. Paun -
Eric Pouech -
Francois Gouget -
Ove Kaaven