Using the Delphi command line compiler on a Continuous Integration server

Recently, I got an email asking how to deploy the Delphi command line compiler for use on a continuous integration (CI) server. Since I’m no longer working at CodeGear nor coding in Delphi I forwarded the message to a few guys at CodeGear mentioning that it would be a good blog post but alas, I never got a response. Geeze, I didn’t think it had been that long guys! 🙂 Anyway…

I figured the question was worth a post if for no other reason than to start a conversation so other Delphi developers could contribute with their experience. Before we begin be sure to read your Delphi software license as I seem to recall there being some sort of issue related to the license regarding compiler deployment.

Getting the command line compiler to a build machine should be pretty straight forward though I’ve never had a need to do it myself since I was always working with the entire source tree including the compiler.

Basically, what’s needed is the Delphi compiler and the DCU/DCP’s from the products “lib” directory which means.

  • DCC32.EXE
  • The lib directory from your Delphi IDE source path

Aside from that here are some other suggestions for a build machine:

  • Using command line options (or a dcc32.cfg file) always specify an output path for the compiler, never place project related output in the same directory as DCU/DCP’s that are shipped with Delphi
  • Make sure you do a “clean” before each new build meaning run a process that deletes all of the compiler produced output from the previous build and verify that it actually works!

Be sure to read Language Reference Guide as I recall working with Nathan Tawill years ago on it and it was very good.

Lastly, another option would be to simply install a copy of the product on the build machine. Oh yeah, be sure to ask CodeGear to create an install that will take care of all this for you.

See also:
Other continuous integration posts
Video: Setting up a continuous integration environment

Ok, that’s my quick and dirty write up, your turn, what’s missing?

14 thoughts on “Using the Delphi command line compiler on a Continuous Integration server

  1. Well, using dcc32 instead of MSBuild seems to have the added appeal of minimal, xcopy-style deployment of the build tools (don’t have to install RAD Studio or muck about with the registry). Heck, it might even be possible to simply check out the compiler itself (and libraries) from source control during the build process – that would truly warrant for a long-term reproducable build even across compiler updates.
    I just tried how far I would get with Steve’s instructions and found that dccc32.exe and the lib directory are not quite enough: So far I also had to add rlink32.dll (and brcc32.exe and rwcore32.dll but that’s just because we don’t check out res files into CVS) and currently I’m stuck in the linking stage (or rather: the compiler is) with an error from RLINK32 about an unsupported 16bit resource in a DFM file. This compiles fine (also from the commandline) on the machine where I have RAD Studio installed. Any ideas?

  2. I have had good success in D6 with a simple copy of the bin and lib folders. Our build process makes sure to rename the project.cfg and generates clean versions of these files to make the build a bit simpler. We drive the build process with custom nant tasks and have not given the msbuild bits much of a try under D2007.

  3. Nick,
    Ok, you’re right you did eventually respond of course, after I sent a follow up to checking whether the first message got sent to the spam folder. I never did hear from that other guy. 🙂

  4. I’m stuck in the linking stage (or rather: the compiler is) with an error from RLINK32 about an unsupported 16bit resource in a DFM file.

    You can use "convert -i -b *.dfm" to make all your dfm files binary. That way, RLINK32 can handle them.
    We can build executables on our compile server here, but cannot run them due to the message:
    "This application has failed to start because rtl100.bpl was not found. Re-installing the application may fix this problem."
    If I copy over all the required bpl files, the application works, but we would prefer to statically link these files into our executables. Is there a method of achieving this?

  5. Jos,
    If you’re getting messages about missing runtime packages it means your compile server is building for runtime packages. Run dcc32.exe to see the command line options for the compiler to build without packages.

  6. Steve,
    The problem seems to be that I need to copy all .dcu files to the build server to be able to do a static compile. We have a build server on which we do not want to install Delphi, but simply copy over dcc32.exe and all required libraries. This means we need to figure out which dcu files belong to which libraries and copy those over. It’s a quite a bit of work, but ultimately makes the whole build procedure much more transparent. We’ve new written a ‘dcp parser’ which tells us which dcu files we need.
    It would have been much more convenient if there simply was a static library format we could use instead of copying over all dcu files, but I’ve not been able to find this, so I’m assuming it does not exist.

  7. Jos,
    That’s absolutely right. Although for Delphi itself it’s easy because all you need to copy are the DCU’s from the "lib" directory. For third party components etc. you’ll need to find the same set of files to copy.
    You’re right about the static library idea, it does not exist. In the Delphi world the DCU/DCP’s are the object files needed by the compiler for linking the runtime. Btw, DCP’s are only required if you’re using packages.
    I’d suggest you ping Nick Hodges at CodeGear and ask him for a Continuous Integration server install for the compiler/RTL bits. I’ve mentioned it to him but it’s really something that needs to be demanded by the customer base.

  8. Maybe someone could make an installer program to automate the installation of this CI.. i.e. a collection of all the right files that are needed placed onto a CD-ROM with a batch program or a console installer of some sort. No one could sell the cd-rom due to copyright issues but maybe it could be automated in an extraction process somehow so that it wasn’t shipping the DCC32 but just prompting you to insert your CD rom so it could collect the right files.
    Or, codegear could build this cd-rom for people as an extra for free or for $20 or whatever added on to the delphi price.
    The problem always would be the third party components and I think there is really no way to solve the third party component issue.. because the installer would have to query the internet and find the right third party component files to download and extract the DCU’s/Pas files from 😉

  9. Why did someone email Steve about a CodeGear product, when it seems that when it comes to Delphi, he has amnesia. They would better have been served sending an email to either CodeGear, or posted on the Codegear newsgroups, or to the Delphi gurus that are still using Delphi.

Comments are closed.