I’m not saying it can’t be done, just that it’s silly and a huge waste of time for both component developers and users to not have a unified, structured, standard way to distribute and install components.

I’d be very curious to see a Mere-Moments guide to your process of installing components using just version control in an automated way. The parts that give me headaches are correctly registering the library paths as well as getting the bpls built. I generally consider it a Bad Idea to commit bin artifacts into source control so those bpls need to get built somehow, and some components can have up to 5 or 6 different packages that need to be compiled. Perhaps I’m missing something but I fail to see how proper source control and a few registry entries will get those bpls built for me in an automated fashion.

Anyway, I look forward to your ideas on this, I’ve beat my head against it for so long that it’ll be good to have some fresh perspectives. My goal is to someday just have a nice CruiseControl script that can fully build out a build environment.

Oh, and the 4 page install guide is for our new developers that should know how to install components manually. We make them go through it at least once so they know how.

Why WinRAR is better then Zip

http://www.codinghorror.com/blog/archives/000798.html

Why 7Zip is better then WinRAR

http://www.codinghorror.com/blog/archives/000799.html

Zip has server us well, but it is past its prime.

Maybe CodeGear should make a publicly available installer that works in the same way?

We’re in the process of linking all third-party code to our projects in svn. That way, all a developer needs on their workstation, is Delphi and svn. The problem with this, which Shawn touched on, is that its ridiculous having to load/unload the design time components, especially when we have quite a few projects. We’ll probably have to write a little script that does the loading/unloading of the components (modify registry) but that requires Delphi to be closed.

Shawn: So why haven’t you automated it? If you use their installers, it *will* take you four pages and at least half a day to get everything set up. But if you *don’t* use their installer every time you set up a new computer — if you use your revision control well — then setting up a new computer is as simple as setting your PATH correctly and importing one or two Registry keys.

In fact, I think that merits another Mere-Moments Guide. I’ll start working on one.

Part of what I constantly struggle with is how to quickly deploy a build environment, going from a fresh install to a Delphi that can build our products with *minimal* user intervention. Many components won’t work unless you modify the library path and also need to be built/compiled and so if we only had a .zip that means hand adding all the paths into the library and hand building, which becomes a huge pain when you have at least a dozen or more components you need installed. A zip file may be nice for the solo developer but it’s hell when you step up to teams or the corporate level and start caring about automation and solid testing.

So while I agree that it’s better to have something that you can commit into version control there still needs to be some level of automation in installing it in order to build out full dev machines quickly.

For years I’ve wanted CodeGear to create a unified component packager/installer that bundles components correctly and in a way that is both versionable as well being able to worked into an automated script. Instead, because there is no standard and no solid guidelines from CodeGear, we have this hodge-podge of random zip files, massive installers, home-grown third-party utilities and everything in between. Our corporate install document that we give to new developers trying to setup Delphi is 4 pages long and there are at least 6 distinct methods in which various components are installed. It basically sucks.

If source code is offered, you can just install it anyway you want after the initial installation. However, for different reasons some component vendors don’t even offer source (like Atozed) and therefore it doesn’t make sense to not provide an automatic installer that takes care of the registering of the design-time packages and path modifications.