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.
- “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
- “Release configuration – All platforms”
- “Conditional defines”: add
RELEASE
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:
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:\Binaries exists and you have write access to it
1. Set Output directory to C:\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+
Uwe Raabe
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 to C:\Binaries\Project1\Project1.exe here 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.
You may try
$(MSBuildProjectName)
It looks like the .dproj is this using itself too, for instance as this part:
<Import Project="$(MSBuildProjectName).deployproj" Condition="Exists('$(MSBuildProjectName).deployproj')"/>
–jeroen
I’ve opted for the [Archive.is] DDevExtensions; I thought this VM had it installed, but apparently I forgot installing it as [Archive.is] IDE FixPack by the same author was installed.
.
The Wiert Corner - irregular stream of stuff 