Approach #1[]
- A free third party plugin called GExperts has "Project option sets" that can be used to set this up.
GExperts Web Site (this was suggested by Ain Valtin in the Delphi Newsgroups)
- Another free add in is DDevextensions which can handle different user defined project options sets
DDevExtensions created by Andreas Hausladen
Approach #2[]
Alternatively, one can use this approach:
- Set up multiple .CFG files for each type of build ("development," "release," etc.)
- Create batch files for copying the appropriate .CFG file to the folder where the Delphi Project (.DPR) file resides.
- Add the batch files to a Project Group. They can be invoked from here.
(this was suggested by Ingvar Nilsen in the Delphi Newsgroups).
Thanks!
(More on Approach #2) How Delphi uses CFG files to set compile options[]
Although this is documented (and has been the subject of various newsgroup posts) the following should be a useful description of how Delphi handles compiler options and how it uses the various CFG files.
It is particularly important to understand this if you want to generate a "development" build with a particular set of compiler options, and a "release" build with different options.
As an example, in a development build, you might want to have optimization turned off (otherwise you can't inspect local variables in procedures or functions if Delphi has optimized them into registers). In a release build, you might want to turn optimization on, but turn off the debug options to create a more compact executable.
Usually you use the IDE to develop and debug your code, and the command-line compiler to generate the executable you wish to deploy. The command-line compiler will generally be called from a batch file which will also compile the help file, and create the installation package.
There are various ways of specifying compiler options for a build:
- via the Project/Options/Compiler and Project/Options/Directives/Conditionals dialog in the Delphi IDE.
- in your source code (e.g. {$R+} to turn on range checks).
- by specifying parameters on the command line when using the command-line version of the compiler (e.g. dcc32 MyProject /$R+).
- by adding to the file dcc32.cfg in the folder where the Delphi executable is stored.
- by adding to the file dcc32.cfg in the folder where your project file is stored.
Unfortunately the way Delphi handles compiler options specified in each of these places makes it tricky to seamlessly generate development and release versions. In particular, you need to be aware of the following behaviour:
- Delphi isn't smart enough to know that a conditional define has been changed when performing a "make". If you have defined or changed a conditional symbol on the command-line of a DCC32 compilation, or in the Project/Options/Directives/Conditionals dialog for an IDE compilation, you must do a "build" in order for all units and include files to "see" the conditional symbol's value. So you'd better always do a "build". Make sure your batch file that performs the dcc32 compilation has the /b option specified. Since the Delphi compiler is very fast, it doesn't take much longer.
- The only way to specify a "global" conditional symbol is via the command line (e.g. dcc32 MyProject /b /dfred would define the conditional symbol "fred" for all files in the build), in either of the dcc32.cfg files, or in the Project/Options/Directives/Conditionals dialog. You cannot specify a global conditional define symbol in the project (.dpr) file. A conditional define specified in a source file only applies to that file and any include files within that file.
- Similarly, compiler switches specified in the project (.dpr) file only apply within that file.
- When Delphi performs a compilation from the IDE, it sets the compiler options and defines from the Project/Options/Compiler and Project/Options/Directives/Conditionals dialogs. The settings are also saved in a file called <Project Name>.cfg in your project folder. While you could edit this text file it isn't advisable, as Delphi will overwrite it when the project is saved. The compiler options can then be modified by directives within your source.
- When Delphi performs a compilation from the command-line using dcc32.exe it gets more complicated.
- The compiler options are first set to default values (you can see what these are by typing dcc32 with no arguments).
- Then these settings are overridden by any settings in the file dcc32.cfg in the Delphi executable folder, if the file exists. Then these settings are overridden by any settings in the file dcc32.cfg in your project folder, if that file exists.
- Then these settings are overridden by the settings in <Project Name>.cfg in your project folder, if that file exists (which it will if you have used the IDE to compile your project).
- Then the settings are overridden by any command-line switches.
- Finally, the compiler options can then be modified by directives within your source.
The main unwanted effect of the above behaviour is that, in the case of compiler switches, the settings in the file <Project Name>.cfg (i.e. the IDE dialog settings) will always override any settings in the dcc32.cfg files. This means that you can't have your "release" compiler options set by dcc32.cfg and your "development" compiler options set by the IDE dialog settings. One way to avoid this is to "hide" the <Project Name>.cfg file for command-line compilations. Then you can place all your "release" version compiler settings in dcc32.cfg and know that they won't be overridden. Your batch file would look like:
del MyProject.cfg.saved ren MyProject.cfg MyProject.cfg.saved C:\PROGRA~1\Borland\BDS\4.0\Bin\dcc32.exe MyProject /b /dReleaseCompilation ren MyProject.cfg.saved MyProject.cfg.
Or you might just delete that file. Since the IDE does not use it, it will not miss it, and on the commandline you will only do release builds.