On December 8, 2002 03:27 pm, Patrik Stridvall wrote:
It is faster. Mucher faster. Using cpp/gcc -E needs to fork a new process for example.
What?!? You got to be kiddin', right? If you can measure any difference in build time between the forking gcc -E and using wpp I'll give you a dollar in small change.
I personally have only tried piping every file parsed by winapi_check through "gcc -E" and it is was unbearably slow, so I removed the code. The parsing it itself can't possibly taken that extra time.
So I'm pretty sure that I can measure it, yes.
However, the big question is not if it is measuarable but rather if it is worth the cost or not. So, yes, I agree that we need to discuss the question.
On Linux process creating is extremely fast, and we do fork 1000s of processes while building wine, this sort of argument is just silly.
Well, it is not really the "fork" in it self that is the problem it is the overhead of loading and initializing gcc and that sort of things.
By the same rationale I suggest having a complete copy of gcc, ld, nm, and whatever tools we use while building wine.
It is not primarily a question of having a complete copy of whatever. It is a question of having whatever accessable as functions in a library to avoid a lot of unnessary overhead.
It would be very nice it something made a GNU C compiler library to support among other things only running the preprocessor.
So no, if speed is the only argument, I say we get rid of it: it's not worth maintaining a fraction of all that additional code.
1. Depending on "gcc -E" will make it harder to port wrc to Windows. 2. It might be less flexible (not sure though).
And then of course using "gcc -E" would possibly cause a GPL violatation. Not that it would matter very much if wrc and friend were GPL:ed.
WTF are you talking about?!? How did you figure this one out? Really, this is simply false, you can fork GPL programs all you want, and cause no GPL violation.
The FSF claims that you forking and calling a GPL:ed executable is the same as linking with a GPL:ed library and calling functions in that library.
This is of course absurd and would IMHO opinion nether fly in a court of law but still....
Sure wrc and friend are under a GPL compatible license (LGPL), so it wouldn't be a direct violation. However Wine has a policy that we do not link with GPL:ed libraries regardless in order to avoid possible problems for companies working with Wine so no we really can't make wrc depend of "gcc -E".
On December 8, 2002 06:01 pm, Patrik Stridvall wrote: [it seems that there are resons to keep wpp, but since it's a slow evening, I will respond... :)]
I personally have only tried piping every file parsed by winapi_check through "gcc -E" and it is was unbearably slow, so I removed the code. The parsing it itself can't possibly taken that extra time.
So how do you account for the fact that compiling a .c file is fast? It certanily does a hell of a lot more than preprocessing. Look: [dimi@dimi server]$ time gcc -c -I../../wine.src/server -I. -I../../wine.src/include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o trace.o ../../wine.src/server/trace.c
real 0m5.276s user 0m4.129s sys 0m0.102s [dimi@dimi server]$ time gcc -E -I../../wine.src/server -I. -I../../wine.src/include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o trace.o ../../wine.src/server/trace.c
real 0m0.538s user 0m0.166s sys 0m0.012s
In other words, preprocessing is like 10% of compilation, so it can't be unbearably slow. Something else is wrong.
The FSF claims that you forking and calling a GPL:ed executable is the same as linking with a GPL:ed library and calling functions in that library.
Do you have a reference to this? Never heard of something like this before.
On December 8, 2002 06:01 pm, Patrik Stridvall wrote:
It would be very nice it something made a GNU C compiler library to support among other things only running the preprocessor.
Um, you mean like "cpp"? The debian packagers have even split it out from the gcc package for convenience, the package description explains;
--------- [snip] The GNU C preprocessor is a macro processor that is used automatically by the GNU C compiler to transform programs before actual compilation.
This package has been separated from gcc for the benefit of those who require the preprocessor but not the compiler. [snip] ---------
so clearly it can be done, and this is presumably for the reasons Dimitrie mentioned - preprocessing can be a useful (and much faster) subset to separate out from the compilation process.
But as for the GPL argument against using the GNU C (pre)compiler from a run-time (ie. "forking/exec of 'gcc -E' is like linking to a GPL lib"), I find that rather hard to believe - especially as invoking "gcc -E" can be framed in very user-supplied terms. Eg. if the user is able to (in theory) configure the program to exec() any precompilation programs (and command-line options) they want, then who is going to sue *who* when the default value for that setting just happens to be "gcc -E" when the program installs? Richard Stallman will sue Redhat? Or will the FSF begin a crackdown against adolescent nerds who illegally point GPL-incompatible configuration files to GPL-licensed precompilers ...? I really don't think this should be a cause for concern.
Cheers, Geoff