The Art of Delphi Programming

There are weeks when bug findings are just going to agglomerate. Fixing them as soon as possible then leads to multiple releases in a short time frame. Sorry about that (well, not really), but nothing comes without a price to pay.

Another small update for  DprojNormalizer is available. This one is only relevant when you have quite a number ( > 10 ) of build configurations in your project, where the hierarchy sometimes gets broken after normalizing.

Thanks to Tobias Reißenweber for bringing that to my attention.

Update: This turned out to be way more complex as expected! V2.2.3 should be the version to go. The good news is, that I learned a lot about the internal assumptions made by the IDE developers.

There is a small update for DprojNormalizer available. The only change is that the entry for SanitizedProjectName is moved to the beginning of the property group. This allows the use of this variable in subsequent properties.

I stumbled upon this when working on a project where $(SanitizedProjectName) is used in the DCU output path to have different DCU paths for each project inside a project group. This reduces the chance of linking the wrong DCU files when working with different conditional defines or settings between projects sharing some source files.

Although this definitely worked some time ago, this entry now resolves to an empty string. The reason is the changed sorting of the dproj file due to the use of DprojNormalizer. The system tries to resolve the DCU output path while SanitizedProjectName is still not defined yet.

BTW, I know it has been rather quiet here during the last few months. Rest assured there are some nice things cooking in the labs, so stay tuned.

Unless I already told you privately, you might not be aware of an undocumented (well, at least before today) option to adjust DprojSplitter to your needs.

By default DprojSplitter splits the following entries in each PropertyGroup of a dproj file:

• Debugger_RunParams
• Debugger_RemoteRunParams
• Debugger_HostApplication
• Debugger_RemotePath
• Debugger_RemoteHost
• Debugger_EnvVars
• Debugger_SymTabs
• Debugger_Launcher
• Debugger_RemoteLauncher
• Debugger_IncludeSystemVars
• Debugger_UseLauncher
• Debugger_UseRemoteLauncher
• Debugger_CWD
• Debugger_RemoteCWD
• Debugger_RemoteDebug
• Debugger_DebugSourcePath
• Debugger_LoadAllSymbols
• Debugger_LoadUnspecifiedSymbols
• Debugger_SymbolSourcePath

If you want to modify or extend this list, you have to provide a configuration file for DprojSplitter with a list of all PropertyGroup entries to be split. The file has to be named DprojSplitter.cfg and has to reside in the IDE AppData folder (which is %AppData%\Roaming\Embarcadero\BDS\19.0\ for Tokyo, adjust the number to your IDE version). The file should contain one entry name per line.

Be aware that such a file will override the default list shown above. So better make sure to include that list in your file unless you explicitly don’t want some or all of those entries to be split.

F.i., if you want the DCU output folder be split, you have to add DCC_DcuOutput to the above list.

There is a new version V2.1.0 for DprojNormalizer available, which targets a problem when using option sets and/or build events. Thanks to Peter Sonderegger for bringing this to my attention.

Be aware that this version may change the sorting of your dproj files triggering a version control change. Well, it obviously does that – otherwise, what would it be good for?

The new version can be downloaded here:  DprojNormalizer