DprojNormalizer for XE7 and XE8

I just uploaded Version 1.0.1 of my DprojNormalizer plugin. No internal changes – only versions for XE7 and XE8 are included here. If you don’t need those you can simply skip this version.

About Uwe Raabe

Addicted to Pascal/Delphi since the late 70's
This entry was posted in Delphi. Bookmark the permalink.

7 Responses to DprojNormalizer for XE7 and XE8

  1. David Heffernan says:

    Do you know if it’s possible to split the .dproj file into separate parts. One part for the settings that are essentially static, e.g. compiler options, and one part local to a specific user, e.g. active platform and config? This is possible in VS user an additional .local project file. I wonder if you know whether or not Delphi will read in the information from another location. If it did, your tool could do the work of moving that per user state to a separate file, not tracked by revision control.

    I’ve not been able to find a way to do this, so I have a feeling that it’s just not possible.

    • Uwe Raabe says:

      Nice idea!

      A plain split does probably not work in all cases. There might be missing entries in the global file and someone doing a plain checkout has no user file at that moment to fill these in. In addition, it should still work even without such a plugin installed. So on Write these settings should be reverted to the original state while on Read they are overwritten with the user settings.

      I will put this on my research list.

  2. Ralf Kaiser says:

    “Splitting” the DPROJ sounds like a job for “OptionSets”, it is basically the same.

    • Uwe Raabe says:

      So, how do you make the IDE store any changes of a specific kind in the OptionSet instead of the dproj file? In addition, not every setting can be used inside an OptionSet.

      • Ralf Kaiser says:

        OK, there is no automatic that stores one change there and another change there. The user has to know what to edit where. Thats why i said “basically the same”, it not exactly what the original poster wanted.

        We use Option sets in a large team to define settings that should not be alterd by everyone. It is a policy that noone should alter an option set and they are marked as “assume unchanged” in our version control, so they cannot be commited accidentally.

        (BTW: what cannot be used in an option set? – Currently i have no Delphi here to check that)

        • Uwe Raabe says:

          Application settings (f.i. themes, high dpi, styles, LIBSUFFIX in packages), Versioninfo, Runtime packages – just to name a few.

          • Ralf Kaiser says:

            OK. I see. (although i never missed these options in an option set cause they are controlled/set by the build server in our working setup)

Comments are closed.