The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,640 other followers

Delphi: path names both in .dpr and .dproj, why? (refactoring – How to reorganize the folder structure of my units in Delphi? – Stack Overflow)

Posted by jpluimers on 2012/09/27

Cool: learned something new here:

About the path names of files being in the .dproj as well as in the .dpr:

@Jeroen – Looks like msbuild might need those entries, otherwise they’re possibly redundant, AFAICT… In any case, there is not much editing involved, just delete ‘dccreference’ entries and then a ‘save all’ in the IDE regenerates them. – Sertac Akyuz

–jeroen

via: refactoring – How to reorganize the folder structure of my units in Delphi? – Stack Overflow.

14 Responses to “Delphi: path names both in .dpr and .dproj, why? (refactoring – How to reorganize the folder structure of my units in Delphi? – Stack Overflow)”

  1. brianfrost999 said

    I got fed up with dproj complexity. Check out my DprojMaker dproj generator tool at http://delphi-divining.blogspot.co.uk/

  2. WarrenP said

    Sounds like a DPROJ generator and NOT CHECKING ANY DPROJ FILES IN to version control would let me do command line builds without ever comitting local workstation paths from developer machines. But Eric’s idea of living without search paths is hell too. I refuse do to that. Library paths only? that really really sucks.

    Warren

  3. Bfrost said

    The dproj can be a nightmare. I spent months trying to get XE2 remote debugging working on an app which debugged fine in D7. After trying all suggestions I deleted the dproj in desperation and let Delphi recreate it. Lo it all started working. If your app has been through multiple Delphi’s, your dproj is probably a mess.

    • jpluimers said

      That reminds me of a similar story when debugging. Indeed ditching the .dproj and manually re-entering compiler settings and such solved it.

  4. Uwe Raabe said

    What bugs me most is that to include a unit in a project the IDE includes it in the uses clause of the dpr. IMHO this is completely unnecessary to please the compiler as long as the unit is used elsewhere in the project and lies in the project folder or in the unit search path.

    On the other hand it is sometimes necessary to include a unit into the project to make use of form inheritance or the different search functions.

    I would really like to have the dpr uses clause be decoupled from the dproj dccreference section.

  5. Eric said

    An even simpler alternative is to just delete the dproj, and load the dpr in the IDE, the dproj will be reconstructed.

    • jpluimers said

      You loose a lot of .dproj information then (platform settings and search path information for instance).

      • Eric said

        Just setup your default settings and use .inc for the rest of options, and don’t use project search paths, you’ll only lose version info, and version info has to be handled separately for release builds anyway, so not great loss.

        Project paths are almost always a sign of problem IME in terms of team organization, as their only point is to make project-specific forks of shared libraries possible, which is always a bad idea. Global IDE paths work well, and don’t hurt performance measurably IME, even over large code bases (tens of thousandths of units in hundreds of folders), and they promote unit and file name unicity, which is a plus in itself.

        Also since dproj cannot be safely shared in version control (as they contain local settings), having any form of advanced project config is problematic at best.

        Finally, .inc with compiler directives is preferable to dproj options, as they’re more finely controllable and enforceable across a team (that’s also why all libraries out there rely on them). The only relevant overall granularity in practice is debug vs release, and that can be take care off via default settings for recreated dproj

        • jpluimers said

          Great comment! You should make a blog post or conference session out of this.

          The only drawback with .INC is that it often confuses the IDE for ifdef kinds of constructs. Since those should be localized anyway, that is not much of a problem though.

  6. C Johnson said

    Delphi is the master at redundant, easily corrupted project information. Paths are only the newest step in the saga.

    • jpluimers said

      The paths in the .dpr are needed for backward compatibility.

      • Andreas Hausladen said

        Not really. The compiler only looks into the .dpr file and has no meaning of the .dproj file. So it isn’t backward compatibility. It is still a requirement by the newest compiler.

        • jpluimers said

          But the IDE does, for setting up the commandline for the compiler.

          It could be possible to put everything in the .dpr, but since so few people understand the IDE owns the .dpr, that would lead into massive problems.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: