Delphi Needs a Spring Cleaning

If you’ve maintained a piece of software for any length of time, then surely you know that at some point decisions made in the past are no longer valid, or maybe have proven to be poor decisions over time, and you need to do some cleanup.

Delphi has been around long enough that it is showing signs that a cleanup is required.  One example is all the duplication of project and build settings between the DPROJ and DPK files.  A clear violation of the DRY principle.

Then there are new features, or changes implemented without considering the results.  I think Uwe would agree that the change of the Find dialog to a toolbar and the subsequent breakage of pretty basic functionality that also drives me nuts is a pretty good example.  I could also site changes to Ctrl+C code completion that I have QCed, but remains broken in XE2 (maybe they will fix it in XE3?).

Storing the currently selected target and project configuration in the DPROJ results in developers constantly being prompted ‘Do you want to save your changes?’.  Since there is no indication what actually changed, the safe answer is always ‘Yes’.  Then when you go to check in your source code, you’re either checking in redundant information all the time, or you have to scrutinize the differences to determine it was just the selected configuration and/or platform that changed.  Keeping user selections in a versioned file is simply a bad design because it’s lousy for team development.  If I decide to compile a project for Win64 to target Windows 7, but my colleague is working on the same project under Windows XP 32 bit, and checks out my update he has to contend with all my setting changes just to be able to recompile.

Makes you wonder if any dogfooding is being done in California these days….

9 Responses to “Delphi Needs a Spring Cleaning”

  1. Stefan Glienke Says:

    I honestly don’t understand people that complain about dproj files in version control. Use a proper difftool and just commit changes that are relevant if you care about user selections. Or don’t commit them at all as long as you only change the target platform or something like that.

    Also use a build tool like Finalbuilder if you fear “wrong” settings in your dproj files because someone commited them.

  2. Leonardo Herrera Says:


    The fact that you *have* to second guess what the tool does is a clear sign of something wrong in its design.

    And let’s not even mention the whole component package paradigm…

  3. David Heffernan Says:

    @Stefan We all know how to deal with the issue. But that doesn’t mean that the current design is the best. Do you think it is the best possible design?

  4. Fred Says:

    We leave dproj out of the version control. We use our own proj file instead. Dproj is then autogenerated from the common proj file and a locale settings file. That works very well with our needs.

  5. Stefan Glienke Says:

    As long as one of the main goals of Delphi is to stay backwards compatible we have to go through these loopholes.

    No it is not best design but I know worse things than that (especially as someone who writes software for more than one version - and it’s currently only for 3 - I think I would shot myself if I still had to support down to Delphi 6 or something).

  6. Eric Says:

    The issue isn’t one if backward compatibility but if a design error when packing everything in the dproj.
    I also blogged about it a while back, the dproj is just both pointless and problematic because it agglomerates user and project settings, and also it needlessly replicates settings present in the dpr/dpk, while offering less capability than them.

    The dproj could be dropped it replaced in XE3 and the only thing users would notice would be an improvement in version control management.

  7. Stefan Glienke Says:

    I knew Eric would step in to tell us that we don’t need a dproj file. That is why DWS places all the dcu files in the same directory as the pas files because the output directory IS NOT contained in the dpr/dpk.

    I know he argues using this directory as library path because Delphi is smart enough to not compile these units again if nothing changed (which is not the case until I get a new revision or change compiler directives in my project).

    1. If everyone would use that approach, every time I build my project it would recompile every used 3rd party unit (you know some people use alot of them and most come with sources) because the compiler does not only have access to the dcu but to the pas file.

    2. You cannot support multiple platforms when dcu files are in the same directory as the pas files.

    Guess why people complained about the complicated component installation of f.i. the VTV: because either the dproj file was not in the SVN which resulted in not being able to find the inc file which was in some extra directory or it was not properly setup (wrong search paths)

    YES, I would love if that information was also contained in the dpr file because then using the commandline compiler would not be such pain sometimes (msbuild, yuck!)

  8. Brian Frost Says:

    You make good point about the dangers of a messy dproj. We have just completed a long investigation into why we could not remote debug a very large app which remote debugged fine in D7 but ceased working with the newer Delphi’s. It turned out that because we had faithfully upgraded through every release of Delphi, each version had messed with the dproj and the only cure was to delete the dproj and have Delphi recreate it. Before that, we could remote execute but breakpoints did not work. Goodness only knows what the problem was. We really do need a dproj editor, so far I’ve found that changing the extension to XML and then viewing it in IE does give you some insight into the mess.

  9. Stefan Glienke Says:

    @Brian: check out MSBuild Sidekick which is an editor for msbuild files (which dproj files are)

Leave a Reply