Is there an environment variable or debug indicator?
I am trying to get my logic going without having to call the copy and special registration services of my component. This both takes a long time and can mess up my development machine. I need a way to embed a
If (!DEBUGGING) then
// DO this stuff only on non-debugging "normal" installations
This is not a good solution. This I could do by simply hardcoding a g_bDebug variable setting it = TRUE or = FALSE which is much much easier than embedding a flag in the buried IS compiler settings (which took me about 5 minutes to even find) were it is even easier to forget.
This should be inherent like it is in every compiler. I should know if I am running in the debug environment or deployment environment without having to generate a bunch of code to complicate this. Why does IS as long as it has been out, not have a primitive feature like IS_DEBUGGING_ENV?
#if DEBUG should be an IS primitive. Install shield should always provide the operation mode of the code being in debug or not.
If you try to get me to do something so clunky, then I have a bug waiting to happen in that I have to remember when I turned on debug and when I didn't so I don't build a gelded install.
Why would I want to hide in the complexity of the IS settings the fact that I have bound my app to being debug no matter what environment I have including deployment? In short, I wouldn't.
Things like this are extremely easy to implement if you are the person developing the compiler.
You don't have to specify preprocessor defines on the Build > Settings dialog. I agree that having to set and unset this definition there would be awful. Instead you can specify additional preprocessor defines on your Release's Build tab, in the option "Compiler Preprocessor Defines". This way you can create two or more nearly identical release configurations and choose whether to provide the DEBUG definition on each.
This is equivalent to how Visual Studio does things for C++, except that it isn't automatically set up for you. In our experience, very few people want to have such differences in their InstallScript code, so we've avoided confusing people unfamiliar with such a Debug/Release convention.
