Component installs

[Curt Krueger 1]

 

This may come off as a stupid question or set of questions, but wanted to know what others do for their setup, and maybe my process is wrong and is the source of a lot of pain when updating to the latest IDE when it shouldn't be.

 

First off, all of my components I own, I have the source code for.    So the overall question is, how do you install your components?  Do you go with the default install from the component vendor, and leave their setup in your system and go with it?  Or do you do the install,  and un-do their library paths and rebuild using your own? Some other method?

 

I don't like to have the source code of the components accessible to my app(s) unless I'm debugging said source code.   A lot of vendors put the source code on the library path, and I don't like it.  This usually results in duplicate dcu's popping up which is a pain point for me.   Do you have your component source on your library path for your apps?

 

This is where my insanity comes in, and you may agree with me that I'm nuts, but this is what I do:

 

For components, I have a root directory like DX1033 and within I have a "bpl", "dcu", "dcp" and "res" directory.   I put the bpl's, dcu's and dcp's from ALL of the third party components in these directories, and remove any references from the library path that the vendors put in, and remove any paths added to the environment path variable.  I put the "DX103\dcu" and "DX103\res" into the library path so all future projects can find the 3rd party components.   For any configuration files needed, I put those in the "dcu" directory.    Once everything is in place, I get a very stable build environment.  I don't get the duplicate DCU's issue, or component source pulled in and built within my main projects directories (which has bitten me a lot before this change).

 

This is a long tedious process, usually with the IDE crashing or bugging out many times.   I have many 3rd party vendors (reducing isn't an option, unless I want to get into the component writing market, which I do not).  EACH vendor does their install their own way, some even think putting their BPLs in the system directory is OK, or they add their long path into the computer's environment variable (which drives me nuts).    Then they add their own library paths to the Delphi environment.   

 

If I simply allow the 3rd party vendor install to do their thing, it quickly becomes painful.  Component source is pulled in and built, the built can't find the right dcu, or the library paths are mucked up and I have to constantly figure out why something won't build.

 

I very much dislike the long paths some vendors use.   C:\Documents and settings\username\company name\component set name \source   really?  Now try doing this with 15 component vendors!!  Each doing their own thing? 

 

Comments?  Suggestions?

 

Thanks,

Curt

 

 

[timfrost 79]

I also have many components, all with source.  I always disable the vendor's 'install into the IDE' option.  For the few awkward ones who do not allow this, I have the IDE installed on a previous development machine, do the install there, and then copy over the source and project folders.  And in most other cases I install the source into a 'components' area which is not my production build area - how do you manage to review every source change if the vendor simply overwrites their previous version, as so many do?  After moving the component source into the production build folders (one for each component) I run a FinalBuilder project which builds each component with settings (defined in the FB project) over which I have control.  The FB project also installs each component in the IDE by setting the IDE registry keys for it, and I have a program of my own which sets the library and browsing paths for the IDE exactly as I want them to be.  All the BPLs and DCPs are each in a single folder. I do much the same as you describe for the DCU and resource files for each project, although for some of the smaller components I do not bother with a separate DCU folder.  FinalBuilder is the big timesaver for all this - once set up, you can click once and know everthing will turn out correctly!

[dummzeuch 1517]

After being bitten too many times, I only install the components with the vendor's installer the first time to get the source code (because that's the only way to get the source code for many components). I then check the source code into source control and remove everything that was installed into my IDE(s) and search paths and whatever.

 

Then I compile the components from source (cursing a lot along that process because component vendors simply don't adhere to any standards) and install them into the IDE I need them.

 

Once that works, I document the process and try to automate it.

 

I then test the (automated) process by removing all traces of the components again and installing them.

 

I fix any bugs of the process I encounter then (there are always bugs).

 

After the installation process works, I remove any paths the installation process added to the IDE configuration. Component sources are always part of my projects that use them. I add them as svn:external to the project and add the search path as relative paths to the project.

 

Rinse and repeat for any IDE version which needs them.

 

Once that's done, everything usually works smoothly. But to get there is a pain in the lower back.

[John Kouraklis 94]

I have a separate folder called Libs where I install all 3rd party components. 

 

And all of them are under version control. 

 

I, also, use one of the uninstaller software which generates a report of all the changes the installers do to the system

[Guest]

On 9/5/2019 at 11:01 PM, Curt Krueger said:

If I simply allow the 3rd party vendor install to do their thing, it quickly becomes painful.

I have changed my MO regarding this the last decade. I used to install everything "manually" and keep track of it. Pain, pain, pain. Especially as more platforms was added.

Today i keep a Delphi version together with working 3rd party stuff in a VM. As long as the result is in production i update stuff when needed.

When starting a new project (i.e. big one, not another exe or some such) i make some strategic decisions, Delphi version and so on. And start a new VM.

Actually, a 3rd party lib that do not play well regarding similar considerations may be thrown out for something else between VMs/Delphi versions.

If my client will not listen to me when i suggest "technical debt" needs to be addressed for this or that monies, then i'll keep the VM with D2009 and make adjustments using that.

[Curt Krueger 1]

Thanks for the feedback everyone.    So far, I'm not a fan of VM's (in the past, the "feel" of the performance was what turned me off about them) but I think I'm changing my mind.   Being pretty much ignorant (last time I used one was 2012), what's the goto VM software people use or recommend these days?

 

Thank again,

Curt

[Anders Melander 1815]

I use the policy that all projects must be completely self-contained.

 

Each project has a complete copy (source and installer) of the all the in-house and third party libraries used.

The project search path points to the local copies.

I always build from the source.

dcu, exe and bpl files goes into local project folders.

Everything is under version control.

 

Getting a project setup on a new system is just a matter of fetching the project from version control, running any necessary 3rd party installers (usually just for design time functionality) and installing the bpls. Since the different projects tend to use the same libraries the two last steps are usually just done once.

 

I don't care about what the installers do because I don't use their dcu-files or their search paths. The project itself contains it all.

 

Never had problems with duplicate dcus (since I started doing it this way, that is).

 

There's of course the problem that different projects might use different versions of design-time components, but that is a bit outside the scope of your question.

 

WRT the VM solution I used it a while ago and it actually worked very well. I used Hyper-V with one VM per project. The only problem was that it got a bit tiresome to have to install the same tools in each and every VM whenever there was a change in the toolset.

[Stefan Glienke 2019]

We keep all third party components in a separate git repository and are using Delphi Package Installer (slightly modified version) to build and install into the IDE on a new installation - also keeping all binaries in that repository (via git lfs).

That enables going back and forth between versions without anything else than a branch or tag change of that repository (unless the vendor changes package structures - then it might require running the Delphi PI again)

 

Initial installation or update is done by one developer on his machine using whatever setup or installation routine the vendor uses (I did most of the initial installation ones and try to do them with as little modifications as possible to make updating them a quick thing) and then putting them into the repository.

[Guest]

16 hours ago, Curt Krueger said:

goto VM software people use or recommend these days?

Search here in Delphi-Praxis. More than one extensive thread about it. Good luck!