Preprocessor #defines

Okay, two quick questions: I've seen questions close to these asked before, but either not answered completely, or the answer is 2 years old and things may have changed:

1) Does Unity (I'm using iPhone, but it'd be nice to know if one does and another does not) provide definitions such as DEBUG, or perhaps platform-specific ones like IPHONE or MAC? I'm particularly interested in something like DEBUG (when running in the editor as opposed to a compiled player) at the moment. But platform-specific ones would be good to know about too for writing scripts that can be easily re-used across platforms (like using different input code if it's iPhone versus desktop/webplayer). If so, are these #defines documented anywhere?

2) Does the #ifdef/#endif functionality actually cull code from the final build, or is it translated basically into a sort of run-time 'if' statement?

 

all #xxxx are preprocessor defines. If they are implemented at all (thus they don't fail with an error as they are unknown), they happen at compile time.

At runtime #xxxx does not exist at all anymore.


#ifdef #ifndef #else #endif definitely work, same goes for #region #endregion which is of great use if you work on windows as the windows script editor (as well as VS naturally) supports folding for regions.

I doubt that there is are OS defines. A Debug define makes no sense at all as Unity by definition does not offer debug builds (Mono 1.2.5 has no debugger at all actually and Mono 1.2.5 is what is used atm)

 

What I meant was, is there anything comparable to DEBUG that would take one code path while running in-editor (pressing the play button) so that error messages and the sort could be displayed, and then this same code would be omitted entirely (not merely bypassed) in the release build? Basically the same as you would do for desktop development. In essence, the editor is your "debugger", after all.

AS for OS defines, that would be really useful for obvious reasons. But as I haven't seen any such thing documented anywhere, I tend to doubt it as well. However, since Unity has control over the compiler arguments to Mono, it just seems too obvious a thing to not have been done...

 

Mono is not C++
You don't play the "define till stupid" game on C# commonly, the code by definition is platform independent so you don't have to do OS branches and compiler branches like you have with C++ where every compiler believes its the one and only all knowing god with its own interpretation of the universe (C++ standards).

Worst case example: VC++ vs Borland C++ vs GCC 3 vs GCC 4 vs GCC 4.2 -> at least 4 defines and 4 distinct code paths for some stuff or you are doomed


As for Debug: I would see it as significantly missleading if Debug was missused for in editor running.
Also, the code is not compiled any differently than in the app, would break the idea of "test your code in a real environment" if the editor compiled the stuff differently than the build.
Given that there is a different behavior with Debug.xxx though between editor (-> log window) and build (-> log file) there are some things that are compiled differently.


Generally: don't see anything that prevents you from having own defines and just switch them when you do the release builds

 

Yeah, I understand all the reasons why C# doesn't need it nearly as much as C++ (my native tongue). Still, given that we ARE deploying to radically different platforms in some cases, it would be nice...

And I'm certainly not suggesting that the #define for in-editor running be literally called "DEBUG", just something like "EDITOR" or something sensible like that.

So I take it then if I put a #define in one of my .cs files, that will take effect project-wide.

It means you'll have to remember to remove the #define DEBUG/whatever before release, but that could be really handy for multi-platform scripting like so:

Code (csharp):

1.  
2. #if IPHONE
3.    // Poll the touchpad
4. #else
5.    // Poll the mouse
6. #endif
7.  

Then you wouldn't get any nasty compile errors in regular Unity saying that it doesn't know what all this iPhone business is all about.

 

couldnt that be done with application.? at runtime? I know it introduces like 1 extra compare but that isnt so bad.

But yes I would have liked the target platform to be defined aswell so that when making interfaces to plugins and if/while only supporting 1 platform it would be posible to make a dummy interface (because of the [Dllimport.....]).

 

Yes, it could be done using Application, however, as you pointed out, you still incur the overhead of the check, which can add up if you have several checks in a piece of code that gets executed in an inner loop. Plus, the additional code can add (perhaps nominally) to the build size.

But of course Application wouldn't save you from compiler errors in the cross-platform scenario if you are using platform-specific objects (such as one of the iPhone objects).

 

For Unity 3:
http://unity3d.com/support/documentation/Manual/Platform Dependent Compilation.html

 

Any way to define a preprocessor symbol across all source files before doing a build?

I tend to put in a lot of debug code (including backdoor functionality) I would like to totally remove from my final build. Also I imagine it could be useful for compiling a server and client version from the same source code?

Apart from the possible speed advantage, #defining out code allows you to be very confident it is not included accidentally.

 

No there is no way to do that, at least not yet. I still hope to see it exposed in the player settings by 3.4 as it is rather easy to add yet it makes a major difference in the outcome (ok there is a way but you don't want to use it as it is not project defined but unity global then as it involves modifying the scripts unity uses to call the mono compiler for the scripts ...)

 

For those that stumble upon this ancient thread,

Unity4 supports in-editor defines.

In the Project Settings Inspector (Edit/Project/Player Settings) you will find per-platform "Scripting Define Symbols" in the Configuration section.

Although they're separated by commas you can easily add a '/' to them to 'undefine' them.

Happy editing!