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,706 other followers

Do publish your .dproj/.groupproj in your version control systems (via: DelphiTools)

Posted by jpluimers on 2015/09/22

But I partially agree with the statement that Eric Grange made at DelphiTools as part of his post via Don’t publish your .dproj/.groupproj a few years ago:

Ad interim, .dproj are just a kludge by design

I completely disagree with hist blog post title: in my opinion “Do publish your .dproj/.groupproj in version control systems”

The discussion that followed in the comments was quite interesting: to bad I missed it back then.

Both .dproj and .groupproj are indeed a bit of a kludge. The main reason is that there is little documentation about them on the Embarcadero sites: most of it are threads on the forums.

msbuild

If you remember that basically they are just msbuild XML files, which is part of the .NET 2.0 framework and higher, and both extensively documented and extendable, then it gets much easier.

Coming from a background that includes *nix, I’m very much used to having everything to be built into the sources, and all dependencies either automatically being resolved, or resolved through environment variables.

That is also the way to go with msbuild: it is in fact one of the really useful tips at the Embarcadero MSBuild Overview page.

In fact, Delphi contains a batch file that sets up the basic environment variables, for instance for Delphi XE5 it was:

C:\Program Files (x86)\Embarcadero\RAD Studio\12.0\bin\rsvars.bat

With this contents:

Properties

The broader msbuild concept here is “msbuild properties” which can be evaluated by surrounding them with $(). So $(PATH) inside an msbuild file gets you the PATH environment variable. Similar constructs exist for registry keys and properties passed through the commandline.

One of the things you will find in the root my repositories (for instance the root of the BeSharp.net repository) is a set of Dependencie. files that help resolving external references.

For open source libraries, they refer to the public repository urls, and the names for them used in environment variables.

The core is a dependencies.bat that sets environment variables, and can clone/fetch/update external repositories it depends on.

Then usually there is a batch file to start either Delphi with those environment variables et, or start Visual Studio with those environment variables set.

Without running those, Delphi will complain it cannot find external dependencies: since the environment variables are not set, the path will not resolve and you will get simple path not found errors.

Separate build and development machine

The ultimate place to check if you got dependencies, batch files and msbuild files right is to separate your build machine from your development machine.

There is a really cool post how to do that with Continua: VSoft Technologies Blogs | Building Delphi projects with Continua CI.

–jeroen

via: Don’t publish your .dproj/.groupproj – DelphiTools.

8 Responses to “Do publish your .dproj/.groupproj in your version control systems (via: DelphiTools)”

  1. C Johnson said

    Perhaps a kludge in the past, but now there are LOT of settings in the .dproj file that are not represented ANYWHERE else in the project. DProj files are now essential.

    Watch what happens once you go multi-target, or use different build configurations – those settings are only in the .dproj file now.

    Oh, and where do you think your icon information is stored? Yup, the .dproj. (not the icon itself, but the pointer to it)

    • abouchez said

      .dproj are indeed mandatory for the IDE.
      But there is nothing in the .dproj which is mandatory for command line compilation.

      The multi-target information is done by changing the compiler executable name, and some command line switches (so easily passed as parameters or environment variables).
      The icon is stored in a .res, which is usually generated ahead of time, independently from the .dproj.

  2. We commit our DPROJ files and make sure everything in them contains relative paths. This works well with multiple directories that have the same code. I sometimes have 3 branches on my machine at any given time and it keeps things clean and easy in the IDE. I am not re-setup the IDE and paths with each branch I switch to. We then use FinalBuilder which can read a DPROJ file and use the paths that that is setup in it, and I believe compiles everything directly using DCC and does not use MSBuild.

  3. Eric said

    If you are going to be dependent on batches anyway, there is little point in using MSBuild.

    The Delphi compiler already handles the part that was handled by make/build tools for C/C++ & other old-school toolchains, so there is very limited value left for MSBuild. The portions it could be handling (like rebuilding resource files, preparing bitmaps, etc.) is something it does not handle very well, and certainly not well at all through a dproj, and the same goes for post-processing (integrating debug info, generating installers, etc.) which do not belong in a dproj or groupproj (but on dedicated build environments for release or CI)

    • jpluimers said

      Lot’s of CI hosts have great support for msbuild, which is one of my reasons I like msbuild a lot.

      • abouchez said

        CI hosts do have great support for executable files, don’t they?
        Why add a layer, with verbose XML files, in between?

        • jpluimers said

          Because then you have a common layer of common XML files and the handling of build output for the things you build most: .NET and Delphi.

  4. abouchez said

    My little experiment is just the same as Eric’s.
    I never liked MsBuild (I suffered too much from it in pure .Net projects), and neither publish the .dproj in my source code repository.
    Just like you, I maintain a plain set of simple .bat files. But they are calling the command line compiler. It is very easy to maintain and use. What is the benefit of calling MsBuild in-between?
    I then include the .bat to the source code repository.
    As you stated, such simple/clean execution environment allow to compile the Delphi projects in a plain build machine, with only a view files copied from an existing Delphi, without the hassle to install a full environment, including the MsBuild tool.
    See http://delphi.wikia.com/wiki/Setting_up_a_Delphi_Build_Machine
    Then a single main .bat is able to retrieve all source code from their repositories (private or third parties), then call the compilation .bat with its local folder settings, and eventually run the automated regression tests. I never needed a full tool for this. And I’m able to follow the same exact path under a Linux machine, using FPC as a compiler, and .sh files instead of .bat.
    The less dependencies I introduce (especially into MS proprietary toolchain), the better.

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: