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.
Note that I said LIBRARY. Still running cpp is presumably more lightweight that running "gcc -E".
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?
Exactly, as I said, it would never fly in court.
However that doesn't mean that the FSF doesn't claim it never the less: http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem
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.
No, I don't think it would be a cause for concern either. Still, as I said, that is what they claim. Obviously they are not stupid so it would be very unlikely that they would press the issue. They seem to prefer to use FUD to accieve their goals instead.
On December 9, 2002 07:19 am, Patrik Stridvall wrote:
Note that I said LIBRARY. Still running cpp is presumably more lightweight that running "gcc -E".
Based on what?!? Let's see numbers (one dummy, empty file): [dimi@dimi dev]$ cat dummy.c [dimi@dimi dev]$ time gcc -E dummy.c # 1 "dummy.c" # 1 "<built-in>" # 1 "<command line>" # 1 "dummy.c"
real 0m0.010s user 0m0.002s sys 0m0.006s [dimi@dimi dev]$ time cpp dummy.c # 1 "dummy.c" # 1 "<built-in>" # 1 "<command line>" # 1 "dummy.c"
real 0m0.017s user 0m0.002s sys 0m0.004s
That's pretty fast.
I just remember abandoning the idea of using "gcc -E" for preprocessing in winapi_check because of horrible a speed slowdown.
This obviously is just plain wrong. Numbers clearly show this can't be the case. Initializing gcc (and it's gcc 3.2 which is supposedly slower than other gccs) takes 100ms, not that bad, it's certainly not "horrible".