Can I define conditionals in a unit and use them in other units?

Question

I am working on a large unit, the unit got so large that I decided to split it into 3 units. Let's say these unit names are Main, Common, and Objects. The Main unit uses both the other two units, and the Objects unit also uses the Common unit. There is code in all 3 units which needs to refer to these conditionals.

The problem is, no matter which of the 3 units I define these conditionals in, the other 2 units don't see them. I certainly don't want to copy them in all 3 units. I also don't want to define them in the project, because these units will be used by multiple projects, in which case all projects using this shouldn't care about the conditionals.

Can I define these conditionals in a way that all 3 units will see them, without defining them in the project?

Farmhouse

You might use an include file. – Few

+1. I don't understand the objection to putting them in the project file though. If it's there, it wouldn't affect any other projects that use the units (as long as they're using the units and not the compiled .dcu files), because the defines in the project file would apply only to the project where the defines are applied. Other projects using the units wouldn't know anything about the defines, and would compile the units without them affecting anything. Putting them in an include file would, however, unless the other projects knew to change the include file appropriately before compiling. – Massive

@Ken because no matter what project is using these units, all projects should assume the same conditionals, and not have to worry about them. For example, 10 different projects would presumably need the same exact conditionals. Also, there are 12 conditionals I need to define, I don't expect the end-developer to define all 12 of these in the project when they have no reason to even know these conditionals exist. – Farmhouse

That makes sense. Thanks. :-) I was understanding it differently. – Massive

@KenWhite: Another reason is that the project file gets modified by Delphi all the time, and often gets checked in with more than just intended changes. In order to have reproducible builds (debug and release), we are actively reducing our dependence on dproj files all the time. We even register the libraries we depend on in a different manner for each project and rebuild the search path for all projects into their dproj's when we change libraries or a version. This also happens to add the ability to log which library versions were registered for a project and which were actually used. – Fagaceous

Answer 1

Your only option, for conditional defines, is to put them in a .inc file which you then include in all three units.

However, conditional defines, and $IFDEF are not the only way to achieve conditional compilation. You might consider using a boolean constant instead of a conditional. So long as it is visible in all three units, you can use $IF rather than $IFDEF.

{$IF MyConstant}
  ....
{$IFEND}

Or, starting in XE3, you can terminate the {$IF} with {$ENDIF}.

Personally I tend to favour this latter approach when trying to compile conditionally and don't want the condition to have global scope.

Dumbstruck

I like the {$IF MyConstant} approach. What do you tend to use for MyConstant? Btw, why don't you want your conditions to have global scope? In other words: simply interested in what you are using conditional compilation for. I currently am on a "no conditionals" at all path, except perhaps ensuring compiler version compatibility for older version of our software. – Fagaceous

@MarjanVenema Typically it's for diagnostics/debugging code that we can't afford to compile in to a standard build because of performance concerns. As you know, it's nice not to meddle with project files, and local changes in source code are less opaque. – Dumbstruck

Your other options is to enter them in the project (conditional defines) or pass them on the compiler cmdline :-) – Extraterritorial

@Marco Those options were explicitly denied by the question – Dumbstruck

Teaches me not answer late at night :-) – Extraterritorial