Define conditional symbol in .dpr

[Vandrovnik 223]

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 244]

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 Tuesday at 12:10 PM by DelphiUdIT

[dummzeuch 1653]

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 1857]

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 244]

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 1653]

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 Tuesday at 05:11 PM by dummzeuch

[DelphiUdIT 244]

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 Tuesday at 05:43 PM by DelphiUdIT