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:
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:
I just added support for Delphi XE2 to XE6 in
DprojSplitter V1.0.4 – no change in functionality so far.
As I currently don’t have the time to test the plugin in all supported Delphi versions, please give me a note if anything is not working as expected and I will fix it as soon as possible.
In case you are still using a Delphi version below XE2 you have to be patient. The relevant dproj settings are stored in a different way in older Delphi versions, so supporting those is not just a matter of making it compile, but implementing it in another way.
To justify the effort I would like to hear from you which Delphi versions you would like to see supported, so please drop a short comment here.
Some of you are probably already using my DprojNormalizer plugin for Delphi, which tries to reduce the unwanted differences disturbing your version control system. It does this by forcing a dedicated order of the entries found in the dproj file.
Unfortunately it doesn’t help for those cases where you make changes to the project configuration but don’t want to spread these changes into the version control. For example, changing from Release to Debug configuration or switching to another target platform are some of these changes, but usually all the settings found under the Run – Parameters menu belong into this category. These settings often reference folders or files local to your machine or are in some way not suited for your colleagues systems.
So let me introduce DprojNormalizers little brother: DprojSplitter!
DprojSplitter takes care of these settings mentioned above and stores any changes you made to them in a separate local file with a dproj.user extension (sorry, dproj.local was already occupied). The corresponding settings in the plain dproj will be reverted to the state when it was loaded. When opening a project, DprojSplitter looks for such a dproj.user file and, if found, merges it into the project settings found in the plain dproj file.
This way you can have your local settings private to your system and so can your teammates.
DprojSplitter is similar to DprojNormalizer: if it is loaded it does its thing. If you don’t want that you have to remove it from the installed packages. This might be necessary when you have to make some changes that actually shall go into the version control this time.
You can download DprojSplitter here:
As always: if you find any error or problem, please tell me.