Some tips for your Delphi project options hierarchy
Posted by jpluimers on 2018/08/08
Over the years, various Delphi versions have cluttered the Project Options hierarchy quite a bit. This means that when you walk this hierarchy in the Project Options dialog, you will see many bold entries, indicating they have been changed for that level in the hierarchy.
The most important tip is to keep as much as possible at the top level, preferably using relative paths or paths containing $(...) macros.
I usually fill these entries there:
- “All configurations – All platforms”
- “Conditional defines” having the base conditional defines
- “Output directory” (usually including a relative path that includes
.\$(Platform)\$(Config) - “Search path” with
.\$(Platform)when you nave libraries containing DCU files per platform- You can even do
$(Platform)\$(Config)here if these DCU files are different for configurations (DEBUG/RELEASE) as well.
- You can even do
- “Unit output directory” so each application gets a unique path (so I include
.\$(SanitizedProjectName)\$(Platform)\$(Config)or.\$(Platform)\$(Config)\$(SanitizedProjectName)in the path) - Unit scope names (based onSource: Delphi unit prefixes for VCL applications)
- “Debug configuration – All platforms”
- “Conditional defines”: add
DEBUG
- “Conditional defines”: add
- “Release configuration – All platforms”
- “Conditional defines”: add
RELEASE
- “Conditional defines”: add
I include the $(SanitizedProjectName) because it has the name of your project, which I documented at Source: Delphi XE8 does not adhere the $(PROJECTNAME) in a “Unit Output Directory”, but does recognise $(SanitizedProjectName) including many other macros.
Note:
- Do not use
$(Platform)in the Tools -> Options -> Library Path setting, as at least Delphi XE4 can remove it while checking for invalid paths; see[WayBack] Delphi XE4 LIbrary Path – Delete Invalid Paths deletes critical data! – embarcadero.delphi.ide - I only do Windows development in Delphi (usually VCL), so these tips do not cover other platforms than Win32/Win64.
- Setting the
OutputDirectorywith$(SanitizedProjectName)cause the debugger not to find your executable:
A long time ago, +Uwe Raabe explained that you can use $(SanitizedProjectName) in your project settings to include the actual project name in https://plus.google.com/+DavidNottageDelphiExpert/posts/PcW8CwMQGmH
This works great for DCU output, but not so well for EXE output: when using for instance
C:\Binaries\$(SanitizedProjectName)as target, the debugger cannot find the executable as the compiler puts it in the wrong place.Example with a fresh console project:
0. Ensure
C:\Binariesexists and you have write access to it
1. Set Output directory toC:\Binaries\$(SanitizedProjectName)
2. Set Unit output directory to.\$(SanitizedProjectName)\$(Platform)\$(Config)
3. Run:--------------------------- Error --------------------------- Could not find program, 'C:\Binaries\%SanitizedProjectName%\Project1.exe'. --------------------------- OK ---------------------------The executable is actually at
C:\Binaries\Project1.exe, so the compiler does not take the “\$(SanitizedProjectName)” bit into account.Anyone with a fix for that?
Via [WayBack] A long time ago, +Uwe Raabe explained that you can use $(SanitizedProjectName) in your project settings to include the actual project name in https://pl… – Jeroen Wiert Pluimers – Google+
To make the compiler use the correct path the SanitizedProjectName item must be located before its use in the dproj file. DprojNormalizer assures that since version 2.2.1 and ProjectMagician does so, too. Thus my Project1.exe is written correctly toC:\Binaries\Project1\Project1.exehere on my system.
Unfortunately that won’t fix the main problem, which is that the call to the debugger doesn’t resolve this variable in the first place. Currently I don’t know how this could be fixed.
It looks like the .dproj is this using itself too, for instance as this part:
<Import Project="$(MSBuildProjectName).deployproj" Condition="Exists('$(MSBuildProjectName).deployproj')"/>
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment