View previous topic :: View next topic |
Does your QCC of choice support a precompiler? |
Yes (frikqcc, fteqcc, meqcc, qfcc, or preqcc before hand) |
|
88% |
[ 15 ] |
No (fastqcc, id's original qcc) |
|
0% |
[ 0 ] |
Don't know |
|
11% |
[ 2 ] |
Yes, but I sometimes need to use one which doesn't |
|
0% |
[ 0 ] |
|
Total Votes : 17 |
|
Author |
Message |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Sun Apr 25, 2010 5:07 pm Post subject: Precompilers! |
|
|
was just wondering :) _________________ What's a signature? |
|
Back to top |
|
 |
Chip

Joined: 21 Jan 2009 Posts: 314 Location: Romania
|
Posted: Sun Apr 25, 2010 7:41 pm Post subject: |
|
|
FTEQCC, I'm an optimization freak, and your compiler does the job. _________________ My Projects: Quake 1 Mods | OpenQuartz 2 | ChipQuake |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Mon Apr 26, 2010 12:17 am Post subject: |
|
|
This is more a question of if you ever use a qcc which doesn't support #ifdef / #ifndef than anything else, tbh. Really not trying to advertise, but thanks :) _________________ What's a signature? |
|
Back to top |
|
 |
Pulseczar

Joined: 12 Aug 2006 Posts: 37
|
Posted: Wed Apr 28, 2010 4:29 pm Post subject: |
|
|
Why does a compiler need to support a precompiler? I wouldn't think a compiler would even have any concept of a precompiler. As long as the precompiler gives the compiler compilable code, the precompiler and compiler will be compatible.
Seems like the question one might ask is whether a precompiler supports a compiler. Not the other way around. |
|
Back to top |
|
 |
Teiman
Joined: 03 Jun 2007 Posts: 309
|
Posted: Wed Apr 28, 2010 5:27 pm Post subject: |
|
|
A precompiler builtin in a compiler is a nice feature.
So with a single exe, everything works out of the box.
I use to miss a precompiler on QC for years, but I suppose once you get use to not having one, is not that bad.
Precompilers are a delicious perversion. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Wed Apr 28, 2010 8:12 pm Post subject: |
|
|
If the language is designed such that a precompiler is not really required, you won't really miss one unless you're acoustomed to the aproach.
With that said, precompilers help to cover upgrading things like APIs. Which is why I started this poll.
The question is really 'can I use #ifdef in an extensions.qc to provide correct types to compilers that support it, and fake types to ones that do not'.
precompilers built into the compiler itself are guarenteed to be available.
there are a lot of ways to use a precompiler. and even more ways to abuse them. seriously, #ifdefs *within* #define was never intentional!
as far as quake goes, precompilers can be useful for the quakeworld/netquake split. but also for protecting innards of generic portable modules that take advantage of extensions of the qcc only when those extensions are available, without breaking other qccs. _________________ What's a signature? |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Wed Apr 28, 2010 8:28 pm Post subject: |
|
|
I agree with Spike: while in the past precompilers were overkill, with the current splitted status of QuakeC in engine-specific dialects they became a requirement. And while in the subject, I'd suggest to study a way to allow one to keep one single QuakeC codebase for both SSQC and CSQC using some kind of precompiler directive for functions or identifiers CSQC related, like this:
Code: |
#csqc
void () CSQCfoobar = {
(...)
};
|
_________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Wed Apr 28, 2010 9:55 pm Post subject: |
|
|
fteqcc -DCSQC -srcfile csprogs.src
#ifdef CSQC
void() mycsqconlyfunc =
{
};
#else
void() myssqconlyfunc =
{
};
#endif
is one such use for precompiler.
My personal use of precompiler involves putting the #define CSQC inside the csprogs's defs.qc-equivelent (the system defs anyway).
Then the same qc file can be used for both progs. For dual nq/qw compatibility mods, generally I just include an extra file in one that wasn't in another, which contains just a #define saying to build it for QW instead, then have ifdefs through defs.qc abstracting the differences.
But its best to write a wrapper/function to abstract the differences between nq/qw than to use ifdef for each and every function that uses something that differs. My example is particles.
Actually, on the topic of csqc simplification..
#pragma sourcefile csprogs.src
Add that to your ssqc code somewhere. This pragma will request that fteqcc compile your csprogs.src afterwards. So you only run it once and you get your two progs.dats.
Oh, and another #pragma that I'm not sure anyone knows about...
#pragma noref 1
Put that at the top of dpextensions.qc :D
You ought to put a '#pragma noref 0' at the bottom too. But hey.
You can also '#warning disable Q302' to disable unreferenced defs, or a few other warning ids.
Strictly speaking, pragmas are compiler features, rather than precompiler ones. But hey, whatever. :P
I must admit that it would be nice to have a keyword for the type that basically says 'ignore this object that I'm defining'. Then you can do #ifdef CSPROGS #define csqc #else #define csqc ignoreme #endif. Which would basically make your code sample work (yes, including the leading #). _________________ What's a signature? |
|
Back to top |
|
 |
|