Define conditional symbol in .dpr

[Vandrovnik 224]

Hello,

 

I tried to define a conditional symbol in .dpr file (before "uses"). Well, I can define it:

 {$DEFINE Test}

 

but later in units, this symbol seems to be undefined.

{$IFDEF Test}
 xx; // causes compiler error in .dpr, but is ignored in units.
{$ENDIF}

 

Is that by design (and why?!), or is that a bug? From help (The symbol is recognized for the remainder of the compilation of the current module in which the symbol is declared), I am not sure what they mean by a module: a unit, or a dll/exe?

I defined the symbol in Project, Options, but still would like to know why it is not possible to define it in .dpr.

 

[DelphiUdIT 258]

Like you told, If you want to define global "symbols" you must insert them in the Project Options / Delphi Compiler / Conditional Defines:

 

 

50 minutes ago, Vandrovnik said:

...but still would like to know why it is not possible to define it in .dpr.

You can define it in .DPR like in any other unit, but it is only valid inside that unit.

And there should be no errors. May be your line (I think is about a new unit in the uses clause) is inserted in a bad place (like if the previous line has already a ';' terminator) or should be terminated with a ',' ...

 

Edited June 24 by DelphiUdIT

[dummzeuch 1671]

You cannot define a symbol in the .dpr file to be available in the units (it will be available in the .dpr file itself though). You must put it into the .dproj file (Project -> Options).

 

Alternatively you can define it in an include file and include that file in all units that require the symbol. That latter approach is used by most libraries because a library cannot add anything to the project options.

[Lars Fosdal 1872]

You can also define symbols in an environment variable, but then they apply to ALL projects you compile.
dcc_define=Test;MagicSymbol;SomeOtherDefine
dcc_define being the magic environment variable name which defines the symbols.

Example:

This one defines "foslar" - so that I can include code that I am working on but which doesn't compile in the project and commit/push to git without breaking the build server or messing up for other users.
 

{$ifdef foslar}
procedure DoSomething
begi
  What was I thinking?
{$endif}

 

[DelphiUdIT 258]

2 hours ago, dummzeuch said:

Alternatively you can define it in an include file and include that file in all units that require the symbol. That latter approach is used by most libraries because a library cannot add anything to the project options.

In the past time (surely prior 12.x) I was used to do this, but I stopped 'cause many times the change of the "symbol" define seems that not apply to all units where the symbol was used. It was like if some untis were not compiled.

 

I used the "DEEP_DEBUG" symbol to do a "writeln" for debugging, but sometimes i delete it and the "writeln" was executed the same.

I had to compile almost two times the  project to make a real change.

 

I have never looked into the problem in depth, because when you have it you are usually already busy up to your neck. So I changed the habit of using the definition in the project options.

And when I compile packages (i.e. libraries) ... I always recompile them TWICE.

I don't know if this anomaly exists in the current version, but I don't even want to try it.

[dummzeuch 1671]

1 hour ago, DelphiUdIT said:

In the past time (surely prior 12.x) I was used to do this, but I stopped 'cause many times the change of the "symbol" define seems that not apply to all units where the symbol was used. It was like if some untis were not compiled.

And that was most likely the reason. The compiler only compiles units that have changed. Changing the include file does not change the units. To ensure that a unit is recompiled after a change to an include file, you must do a complete build of the project(s).

 

The same applies to defines set in the .dproj file btw. Changing them does not trigger a complete rebuild.

 

If you want to be really paranoid about this, delete all units from the unit output path. This ensures that every unit will be recompiled. I do that once in a while.

Edited June 24 by dummzeuch

[DelphiUdIT 258]

34 minutes ago, dummzeuch said:

And that was most likely the reason. The compiler only compiles units that have changed. Changing the include file does not change the units. To ensure that a unit is recompiled after a change to an include file, you must do a complete build of the project(s).

The same applies to defines set in the .dproj file btw. Changing them does not trigger a complete rebuild.

If you want to be really paranoid about this, delete all units from the unit output path. This ensures that every unit will be recompiled. I do that once in a while.

I'm aware of this, and this may be logical, but in the past I had to do 2 (TWO) times COMPLET REBUILD. It didn't work with just one. ... but not always, only sometimes.

 

I know that because I allocate manually the "console" depending of that symbol and without this the I/O error will be produced if some "writeln" is executed (confirmed also by debugging).

Edited June 24 by DelphiUdIT

[HeartWare 9]

On 6/24/2025 at 7:09 PM, dummzeuch said:

And that was most likely the reason. The compiler only compiles units that have changed. Changing the include file does not change the units. To ensure that a unit is recompiled after a change to an include file, you must do a complete build of the project(s).

If you change an include {$I} file included in a unit file, that unit file will be detected as modified and will be recompiled with a normal compile (or at least it should, and does in my experience).

[dummzeuch 1671]

On 8/19/2025 at 11:26 AM, HeartWare said:

If you change an include {$I} file included in a unit file, that unit file will be detected as modified and will be recompiled with a normal compile (or at least it should, and does in my experience).

My experience is definitely different: Changing an include file does not force the units that include it to be recompiled.

[DelphiUdIT 258]

1 hour ago, dummzeuch said:

My experience is definitely different: Changing an include file does not force the units that include it to be recompiled

I agree with you, same experience. By now I resolved using a RAMDISK where all my projects are set to save the compiled files (DCU).

Two times per day I'm sure that the build operation builds all, and a simple erase of the ramdisk forces a complete rebuild.

Edited yesterday at 04:27 PM by DelphiUdIT

[mvanrijnen 127]

2 hours ago, DelphiUdIT said:

I agree with you, same experience. By now I resolved using a RAMDISK where all my projects are set to save the compiled files (DCU).

Two times per day I'm sure that the build operation builds all, and a simple erase of the ramdisk forces a complete rebuild.

hm, does the ramdisk makes much difference with building?
 

[DelphiUdIT 258]

1 hour ago, mvanrijnen said:

hm, does the ramdisk makes much difference with building?

No, not in performance. The advantage is that you don't have to delete the traditional WIN64\Release directory for each individual project.
When you erase the disk (1 second), you delete all the temporary directories for all your running projects.

 

And, I have SSD, don't use the disk ....

[HeartWare 9]

21 hours ago, dummzeuch said:

My experience is definitely different: Changing an include file does not force the units that include it to be recompiled.

Okay. Just tried. This Main.PAS file in an empty VCL project:

 

unit Main;

{$I INCLUDE.INC }

{$IFDEF AA }
hfjkdfhkj
{$ENDIF }

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs;

type
  TForm203 = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form203: TForm203;

implementation

{$R *.dfm}

end.

 

 

And this include file:

 

{.$DEFINE AA }

 

Now, compile the program. Then remove the "." from the define (remember to save the file) then compile again - I get an error on the hfjkdfhkj line.

 

So it definitely picked up the need to recompile the Main.PAS file.

Edited 5 hours ago by HeartWare

[DelphiUdIT 258]

If you want I can make a video ...