Diamondback: My first attempt to compile real code

When I got back to the office after BorCon, I wanted to get a feel for how Diamondback’s refactoring tools would work with our real, live production code base.

But I had to install it first.

I was a bit leery of installing it on my production machine. That machine is touchy enough as it is. I mean, we have Delphi 8 code that compiles on some of our development PCs and doesn’t compile on others. (Well, we used to. Then Brian renamed a directory, and his compiler now misbehaves the same way as Sam’s and mine. We have code in our code base that should not compile, but does.)

My best guess is that our Delphi 8 problems have something to do with the different computers having had different combinations of Microsoft Visual Studio, Microsoft Visual C#, and Borland C#Builder installed on them at various points in the past, combined with the order in which we installed Delphi 6, Delphi 7, and Delphi 8 on each machine. But that’s just a guess. When you come right down to it, I really have no idea why the Delphi 8 compiler misbehaves differently on different computers. After the time we’ve spent wrestling with it, I’m just happy that it works (for the most part).

But I wasn’t about to do anything to tick it off. I was not about to install the Diamondback preview on there. (After all, it might look bad if something went wrong and I wasn’t able to compile the app that I’m technical lead on.)

I asked my boss if we had any spare machines around, and unfortunately, we didn’t. What I wound up settling for was a Virtual PC virtual machine.

(If you haven’t used Virtual PC and/or VMWare, they let you run an entire “computer” inside a window. Ward’s Wiki has more info on the VmWare page.)

I created a new virtual machine, installed Diamondback, and then realized that I needed to call IT to join the virtual machine into the domain, so I could see our network drives (where VSS lives). Our IT guys are awesome; Matt was over within five minutes to take care of it. I got latest code and started compiling away.

Now, compiling our code base isn’t quite as easy as just hitting Compile, because we have a large number of third-party components and home-grown components. So the first step is compiling all the packages. Actually, no; the first step is figuring out the dependencies between all the packages, so you know which one to compile first. Actually, no; the first step is removing the TeeChart that ships with Delphi, so we can use TeeChart Professional that we purchased some time ago.

On this first iteration, I never even got as far as that last step (removing TeeChart). But I did nose around and figure out the dependencies between all the packages, and stopped to document them on our wiki, to make it easier for the next guy. And then I started compiling away.

The upgrade to Diamondback, I’m thinking, is going to be about our easiest Delphi upgrade yet. All I had to do was open up the package, tell Delphi to upgrade it to a Win32 package (not .NET), go into Project Options to set the search path and output path (which we’ve never actually had set properly in the project files we check into VSS — I was doing some cleanup while I compiled), and then do the compile. Repeat approximately fifty times. We have a lot of packages.

The very peculiar thing is, every time I compiled a package, Diamondback got slower. And slower. And slower. There was a funny delay whenever I compiled, and there was a funny delay whenever I went into Project Options. In each case, the CPU would go straight to 100%, and stay pegged there for some amount of time — by the time I gave up, it had reached about two minutes (!). Just spinning the CPU; not doing anything else. And after that little interlude, it would happily proceed with the compilation, or would happily pop up the Project Options dialog. So I had to deal with this delay at least twice for every package. And it was getting ridiculous.

Now, Delphi 6 often gives a delay before opening Project Options, but it’s like fifteen seconds, not two minutes. And I never did figure out what was going on. Rebooting the virtual machine didn’t work. Quitting and restarting Virtual PC didn’t work. Rebooting the host system didn’t work. I even tried repairing the Diamondback installation, but I don’t think that was actually working properly, because (a) it ran so darned fast and (b) it never actually prompted me for CD #2. (And no, it didn’t fix the problem.)

And I was only about halfway through the packgaes by this point. Obviously, something was wrong, and it didn’t look like I could fix it with anything short of a reinstall.

But reinstalling software inside a virtual machine is silly. At that point, you’re better off just creating a new virtual machine and starting fresh. But I decided to be a little smarter about it this time.

Leave a Reply

Your email address will not be published. Required fields are marked *