Is there an equivalent to the C standard way of having debug code that is disabled or compiled out for a final release build?
In C you would do something like
I expect this to be a bit of a problem with Unity/Mono but thought i'd ask. If it isn't possible then i'll just write some awk scripts that i can run which will allow for the same kind of behavior by manually running it on my script files before doing a final build.
As Peter pointed out: Currently, Unity doesn't support project-wide #defines, which in my opinion is a very unfortunate limitation. One thing you can do to get this more into reach is vote up the entry on http://feedback.unit3d.com: Editor: Interface for listing preprocessor macros (#define) in build settings. With that feature, the issue (and a lot more issues) would be solved.
One thing you could do under "the right circumstances" is compiling DLLs with Visual Studio that you use in Unity. That way, you could use the defines from Visual Studio. Unfortunately, those "right circumstances" are probably quite rare (usually, you'll want to keep most code directly in the Unity project because it simplifies most things).
So, until I get those defines in Unity, what I'm doing is this: I have a couple of defines in every class file where I need them, and I also have a script that runs through all the classes and does a little bit of code replacement to either "activate" or "deactivate" those code sections (I comment them in/out via script). That way, I have "kind of the same functionality" as I would have with proper project wide defines. It's just a hack and somewhat more cumbersome ... but it works for me in a rather complex project (server/client, different client versions etc.)
The whole code that I'm using for this is a bit too much and too complex (and too unpolished) to post but I can give you a few bits that should be helpful to set something like that up for yourself. So, the code I'm posting here is not "easy copy'n'paste code" but it should get you start it - and feel to ask questions (I can still edit this to make things more clear).
Just a word of warning: Replacing code in your source files can ruin your project if you're not careful. I also had a lot of Unity crashes when I developed this (but that was with a much older version of Unity). So either use version control (like the Asset Server) or always keep backup copies. And, speaking of version control: doing these replacements will obviously change your code; and usually, that's not a change you'd usually want to record in your version control - so in most cases, you'll probably just do this for a build and then revert the changes.
answered Dec 22 '09 at 08:54 AM
That isn't strictly possible with Unity as it doesn't support project-wide
You can, of course, do something like the following:
That works for most cases, but if you need to strip out entire classes then you'll need another solution. You could easily write a script to process all your source files to handle the task.
answered Dec 22 '09 at 01:20 AM
Note that you can check Debug.isDebugBuild to see if you are currently running a development build (based on the corresponding checkbox in the build settings). This is a runtime check, so code does not get compiled out as the OP requested.
You can also mark classes or methods with the ConditionalAttribute, which tells the compiler to remove code (and calls to it) unless a specific pre-processor define is present. Here's what it looks like:
This would be much more useful if Unity provided more control over pre-processor defines. (Note that Profiler.BeginSample uses this mechanism to strip profiling hooks from non-development builds. Internally they are using the ENABLE_PROFILER #define, which is perhaps a way to tell if you are in a development build. Probably works for Unity Pro only.)
What does Unity / Mono do in the slightly less obvious case:
To a human this is clearly always going to evaluate to FALSE, and so the compiler should strip the entire code block out. However, from my experience, it is almost always possible to trick a compiler into evaluating a statement repeatedly, even if the statement is always FALSE.
answered Feb 17 '10 at 06:15 PM