Add unit to project is removing a compiler directive from the project source

Question

Should this work this way or am I doing something wrong?

I have this code in my project source:

  {$IFDEF DEBUG}
  ADebugUnit,
  {$ELSE}
  ARelaseUnit,
  {$ENDIF}

I want ADebugUnit to be used when in debug mode but AReleaseUnit to be used when compiling in release mode. This works great EXCEPT when I select to add a new unit to the project. When I do that it will basically process the code and only keep the unit that pertains to whichever configuration the project is currently set to.

For example, if the configuration is set to Debug then after adding a new unit to my project the above code changes to just:

ADebugUnit,

Or if my configuration is set to Release it will change to the following after adding a new unit:

ARelaseUnit,

I have to always restore it back to the conditional statements after adding a new unit. Is there a way to accomplish this without having the add new unit interfere?

I write my own .dpr file and undo the changes made by the IDE. VCS helps. Some things need to be conditional in the .dpr file. — David Heffernan, Oct 16 '13 at 19:57
Unfortunately the IDE doesn't always do a clean job either, and often destroys the entire project file. I've even seen it copy the `uses` clause further down so it was duplicated. — Jerry Dodge, Oct 17 '13 at 01:14
I do want to state that we have a copy of Delphi XE5 that we are evaluating and gave it a try in that environment and it works as expected in the fact that I can have the conditional include in the project source and use the add unit option in the IDE and it will NOT remove the conditional compiler directives. This is what I would have expected to work in Delphi XE2 but does not. — Ann Gossard, Oct 18 '13 at 13:55
Yes. The Delphi IDE really screws up things when related to DRP/DPK. — Gabriel, Oct 16 '15 at 14:55

score 4 · Answer 1 · answered Oct 17 '13 at 02:15

The problem is that the DPR will not respect any $ifdef's in the uses list and will in fact remove them (as you have found) when it re-writes the uses list in response to certain IDE operations.

One option is to never use those IDE operations, such as "Add/Remove Unit" etc and to only ever manage the DPR uses list manually.

Alternatively with a bit of care you may be able to use unit aliases to achieve what you want.

Consider two units where you wish to use either on or the other depending upon the build configuration (debug or release):

DebugUnit.pas
ReleaseUnit.pas

In your project options add a Unit Alias for:

DEBUG configuration:

  UnitToUse=DebugUnit

RELEASE configuration:

  UnitToUse=ReleaseUnit

In your DPR add an entry to the uses list:

  uses
    UnitToUse,

This entry in DPR cannot identify a filename using the "in '' syntax and must instead rely on the actual units required being on the project search path.

Anywhere that you would normally use the DebugUnit or ReleaseUnit, refer instead to UnitToUse. Obviously the name for the alias is entirely up to you.

If the two units have the same interface "contracts" then your builds will switch between these two units simply by changing the target configuration.

If they have different interface contracts then you can still use $ifdef directives in your application code to work with the contents of whichever unit UnitToUse refers to, as appropriate, e.g.

uses
  UnitToUse;


procedure DoSomethingInvolvingAliasedUnit;
begin
  {$ifdef DEBUG}
    // code which relies on the debug unit
  {$else}
    // code which relies on the release unit
  {$endif}
end;

score 2 · Accepted Answer · answered Oct 16 '13 at 18:42

The IDE owns much of the DPR file. Be careful of what you do to it, or you risk exactly what you've observed (or worse — depending on the nature of the changes, the IDE might sometimes decide not to allow the file to be compiled at all!).

Among other things, what this means is that you cannot conditionally include units in the DPR file. You'll have to find another solution to whatever problem you were trying to solve.

For example, maybe you could use the unit from somewhere else in your project instead of the DPR file.

Or maybe you could consolidate the two units into one, and then have its contents conditionally compiled instead.

Or maybe you could just use the debug code all the time since that increases the chances that you ship the same code you tested.

Or, if this problem only occurs when you use the "add unit" dialog, you could just forego that dialog and edit the DPR file manually. There's no other magic behind adding a unit to a project, except that the uses clause gets rewritten, as you've noticed.

Agree, and it's a PITA. There are several things that are either not working in a *.DPR file or the IDE will throw them out occasionally. This is one of them. Single best advice is to put as much as possible into another unit. — JensG, Oct 16 '13 at 18:55
@Rob - We can manually add units as necessary which is how we are getting around it (or fixing it after the fact). Although we are looking into eliminating the conditional altogether which would be the ideal solution. — Ann Gossard, Oct 17 '13 at 14:16

Jerry Dodge · Answer 3 · 2013-10-17T01:22:59.083

To build onto Rob's answer, whenever I have situations when I need to do something like this, I migrate all the DPR code over to another unit, for example AppInit.pas.

unit AppInit;

interface

uses
  Vcl.Forms,
  Unit1,
{$IFDEF DEBUG}
  ADebugUnit
{$ELSE}
  AReleaseUnit
{$ENDIF}
  ;

procedure RunApp;

implementation

procedure RunApp;
begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.Title := 'Sample Application';
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end;

end.

Then your project unit would only have

program SampleApp;

uses
  Vcl.Forms,
  Unit1 in 'Unit1.pas' {Form1},
  AppInit in 'AppInit.pas';

{$R *.res}

begin
  RunApp;
end.

The down-side of this is that the IDE will then be confused as to what type of application it is, and when you go to Project > Options, some features will be disabled, such as VCL Styles. With the right coding, such things can still be implemented though.

PS - Please pardon the fact that I wrote this 100% directly into StackOverflow, so sorry if I goofed something up in that code.

Add unit to project is removing a compiler directive from the project source

3 Answers3