Compiling your project with and without EurekaLog |
  
|
Compiling your project with and without EurekaLog |
|
|
Important Note: Be extra careful when doing batch compilation of projects in project groups, or using external build tools. There are IDE bugs and other issues, which may pass incorrect information to EurekaLog (via OpenTools API in case of IDE). Pay close attention which configuration file is passed to compilers by external build tools. Always double-check the final executables.
A common task for developers is compiling their projects with or without EurekaLog. For example, a developer may want to compile a project with EurekaLog for production (release), but compile the same project without EurekaLog for development (debug).
This use case have a good reasoning: EurekaLog is production diagnostic tool, which means it is designed to report about problems "post-morten", it also means that EurekaLog uses fast-enough approaches, as opposed to using heavy debugging code. Therefore, it is preferable to use debug tools (such as IDE debugger, debugging memory manager, OS's checked build, etc.) to locate issues while developing applications, and use EurekaLog to catch remaining issues "on the field".
And some developers use EurekaLog only for local debugging, so they want to enable EurekaLog for development, but disable it for production.
Important Note: This article will discuss the case when you want to have EurekaLog enabled in one profile, but not in another. If you want EurekaLog to be enabled for both Debug and Release profiles, but with different configuration - please, see Different EurekaLog settings for 'Debug' and 'Release' profiles article instead.
Anyway, the basic idea is that you (as developer) may want to compile your application with and without EurekaLog. And you also need to do this (i.e. switch configurations) regularly. There are several possible methods to do this.
1. (Correct) method #1: Define/Undefine EUREKALOG conditional symbolEurekaLog units are included in your project as this:
program Project1;
Where EUREKALOG symbol is defined in your project options:
EUREKALOG symbol is defined in project's options
Note: EurekaLog post-processing will first check if EUREKALOG symbol is present; if it is not defined - post-processing will be skipped.
You may undefine (e.g. remove) EUREKALOG symbol from certain build configurations (profiles). Do not remove EUREKALOG_VER7 symbol, remove only EUREKALOG symbol.
Important: Please note that settings are inherited. Therefore, you have to remove EUREKALOG symbol from base profile first, then add EUREKALOG symbol to your specific profile (Debug, Release, etc.).
EUREKALOG symbol in Debug configuration is inherited from base configuration
You can add/remove EUREKALOG symbol manually, or use EurekaLog project options dialog. You should see "Profiles" option on "General" page (on Delphi 2009+):
Profiles option indicate EurekaLog is enabled for all configurations (EurekaLog is enabled in Base profile, which means it is inherited to all other profiles)
First, uncheck "Base" profile - this will remove EUREKALOG symbol from base configuration, thus disabling EurekaLog for entire project. Next, check the desired profile:
EurekaLog is enabled for Debug configuration only
You may want to create additional configurations:
Creating a new configuration profile
Custom build configuration is created
Don't forget that settings are inherited, thus you need to enable EurekaLog only in the "leaf" configurations. Alternatively, you can disable inheritance for symbols manually. Anyway, once custom build configuration is created - you can enable EurekaLog for it:
Enable EurekaLog for custom configuration only
If you build your project and your currently selected build configuration does not have EUREKALOG symbol defined - EurekaLog will detect it and notify you:
EurekaLog will notify you when it is not enabled in currently active build configuration
If this is unexpected - you can either switch to another build configuration (which has EurekaLog enabled), or define EUREKALOG symbol for the current build configuration - either via project options (manually), or via EurekaLog project options.
2. (Wrong) method #2: Use "Enable EurekaLog for this project" / "Reset"A wrong way to archive the above mentioned goal is to use "Enable EurekaLog for this project" together with "Reset". "Enable EurekaLog for this project" option will enable and configure EurekaLog for the project, "Reset" will remove EurekaLog from the project. While this may work for many projects (basically - for those, which options were not changed much), this option will not get the desired behavior for all cases. The problem is that resetting options will erase all existing EurekaLog options from the project. Therefore, any further "Enable EurekaLog for this project" option will simply use defaults. E.g. any changes in configuration will be lost.
3. Method #3: Always compile with EurekaLog, but disable EurekaLog at run-timeOne possible method is just have the same executable for all cases. Compile your project with EurekaLog - as you would do it for production/release. Then add check like this at startup:
if ThisIsADeveloperMachine then
where ThisIsADeveloperMachine is your custom function to determinate if you are running on developer machine or not. You may use IsDebuggerPresent function as ThisIsADeveloperMachine function. Or you may read registry for specific "magic" value.
You may also disable only part of EurekaLog - instead of disabling the entire EurekaLog. For example, you may turn off leaks registering (call EMemLeaks.DisableMemLeaksRegistering). Or you may turn off sending (set CurrentEurekaLogOptions.SenderClasses := esmNoSend). Etc.
If you are not satisfied with run-time customization (as it will still add performance penalty at compilation and startup) - then you have to really compile your application without EurekaLog.
4. (Workaround) method #4: Disable "Catch memory leaks"Often a reason behind having EurekaLog disabled is performance considerations. If this is a case - then you can use the following method: enable EurekaLog for your project, keep "Enable extended memory manager" option turned on, but turn off "Catch memory leaks" (and possible some other options on "Memory problems" page - but keep "Enable extended memory manager" turned on).
Long technical explanation 1. You get most performance hit from "Catch memory leaks" option, as EurekaLog has to build call stack for each memory allocation; while "Enable extended memory manager" option itself does not have major impact on performance. 2. It is strongly recommended to keep "Enable extended memory manager" option turned on when possible, as EurekaLog uses MM filter to track lifetime of exception objects. The worst case scenario would be: using Delphi 2007 or earlier, having "Enable extended memory manager" option turned off, having "Use low-level hooks" option turned off - EurekaLog won't be able to track lifetime of exception objects in such configuration.
See also:
| ||||
