Re-use of registered components and libraries
Re-use of registered components and libraries
Hi all. We're currently switching to a new version control system, and we're reconsidering the way we set up our Delphi projects.
We routinely use a set of external components, like TMS, Raize, WPCubed, etc. Any developer will typically work on different projects, and each project can use different versions of those components, depending on when the product was last updated (some are so old they only need updating once every few years).
Our problem is that, in order to be used at design time, a component needs to be registered in Delphi. After doing this, Delphi will try to load that component even when no project is loaded. I would prefer if components were only loaded when a project that references them is opened.
This means we can't load one version of a component for one project, and a different version for another project. We've circumvented this by installing the library components on a mapped drive (W:\Lib). When switching projects, we change the drive mapping to the relevant project's library, and use that. Delphi mostly accepts this without complaining, though it’s a good idea to close Delphi first, change the mapping, and then launch Delphi with the new project.
Now I'd like to get rid of the drive mapping, and only load the (version of) libraries associated with a project when I open that project. Does anybody know how this would be possible?
How do you guys handle these things?
Hi all. We're currently switching to a new version control system, and we're reconsidering the way we set up our Delphi projects.
We routinely use a set of external components, like TMS, Raize, WPCubed, etc. Any developer will typically work on different projects, and each project can use different versions of those components, depending on when the product was last updated (some are so old they only need updating once every few years).
Our problem is that, in order to be used at design time, a component needs to be registered in Delphi. After doing this, Delphi will try to load that component even when no project is loaded. I would prefer if components were only loaded when a project that references them is opened.
This means we can't load one version of a component for one project, and a different version for another project. We've circumvented this by installing the library components on a mapped drive (W:\Lib). When switching projects, we change the drive mapping to the relevant project's library, and use that. Delphi mostly accepts this without complaining, though it’s a good idea to close Delphi first, change the mapping, and then launch Delphi with the new project.
Now I'd like to get rid of the drive mapping, and only load the (version of) libraries associated with a project when I open that project. Does anybody know how this would be possible?
How do you guys handle these things?
What I do is version control the installed libraries within each project's repository.
ReplyDeleteWouldn't this help in your situation, if the library appropriate to the version of the project and Delphi is part of the project repository ?
This would mean each project would of course have ALL libraries that its version of Delphi requires for ANY projects that version of Delphi is used for.
What issues would there be with that ?
PS: I use non-integrated SVN here.
Keep all projects using the same versions of the components and make sure you have automated continuous integration, testing and deployment setup.
ReplyDeleteIf you really want to split everything, then make VMs per project (easy) or different Delphi registry trees per project (difficult).
Jeroen Wiert Pluimers Getting all projects and versions onto a single version of components can be a huge task. It may also introduce defects in unexpected places.
ReplyDeleteWe are doing that at work. We have the C:\Users\Public\Documents\RAD Studio\8.0 version controled in a GIT repository (actually only the bpl, dcp and the Comps directory that contains all the component directories). That allows us to switch between different branches that correlate to the branches in the other GIT repository that contains our source. Our build server also checks out the matching respository before building our source. It works amazingly well.
ReplyDeleteJeroen Wiert Pluimers What you are suggesting is not possible if you have quick release cycles between minor updates while you also are working on the next major version. Our minor updates usually don't contain 3rd party component updates because the risk of breaking changes or unexpected bugs is way to big. QA does not do full tests for minor updates (which would require weeks) but only for things changed (and updating 3rd party source that gets used everywhere would require them to test everything).
I'd stop short of saying impossible, but would question the value vs. the cost. Also, third party component updates may occur at almost any time, and may introduce new defects. At least, I have found it to be so.
ReplyDeleteChristopher Burke If I understand you correctly, that would mean that all projects written in a specific version of Delphi would have to use the exact same component versions.
ReplyDeleteThis is a problem, because if we have to create a new release of a product which was last released with an old version of the library, we'd first have to test it all over to see if a changed component is affecting it, instead of just testing the areas affected by a code change. Especially in custom-made products, the customer often don't want to pay for updates in third-party components that don't add value to the product.
Jeroen Wiert Pluimers I'm afraid keeping all products on the same versions of components is not an option.
ReplyDeleteWe've already had an instance where a single update of a third-party component introduced a bugfix necessary for one product while simultaneously introducing a new bug breaking basic functionality in another product. So product A was forced to update, where product B had to use the previous version. The component vendor fixed the problem about 6 months later, so they had to use separate versions all that time.
As for using VMs to really split the environments, that could be feasible; but it seems rather cumbersome to have to do this for each project. Also, I wonder if our older machines are powerful enough to do actual development work in a VM. But that's a secondary concern (it might even be a good excuse to get management to buy us some new gear :-P).
Stefan Glienke
ReplyDeleteHm... that actually sounds similar to what we do with mappings, except that you're using git to switch between versions, whereas we change a drive mapping.
How do you keep track of which component versions (which revision of the Bpl/Comp repository) match a project's source code?
Currently this is done by branch naming policies. But we are thinking about keeping a file with the component branch name in our source repository so you can easily switch.
ReplyDeleteRest is done by organization and me being the cerberus of that repository ;)
Martijn Coppoolse As long as the names and locations of the libraries are the same - you could have varying versions of the library per library version. The key here is to ensure design/runtime match and IDE/compiler/library match - for any checked out code.
ReplyDeleteBill Meyer hence the choice I gave...
ReplyDeleteWhat we do is have the source/binaries of every version in our repository. We then do a "copy" of the version into the relevant projects. So each project has its own version of the components that it requires. That gets updated of course as the project matures and we update components. We also wrote our own mini "installer" called "package manager" that takes care of registering the installed packages with teh IDE. It scans a folder (and subfolder) for install files that say which BPLs to register, paths to add to the Delphi library path, DLLs to move to the system path etc. If we switch to a new project, or an old version of the existing project, we run our package manager again and it will uninstall the packages from the previous version and register the new one. The package manager took a bit of time to write, but its worth it. Now we can go back in time and revert to the 3rd party components we used with a given revision
ReplyDeleteDavid Novo That package manager sounds intriguing. You wouldn't happen to sell or have open-sourced it? :-P
ReplyDeleteIt would make Jeroen Wiert Pluimers's third option more feasible; and allow us to keep our libraries in a single repository, which could then be included as a subrepository in each of our projects. Each project could then stay at the revision that's appropriate for that project. Updating the components for a project would then just be a question of checking out the latest revision for that Delphi version, running the package manager, restarting Delphi, and testing the application with the new components...
Martijn Coppoolse Check out Delphi Package Installer on Google Code. It does that.
ReplyDeleteStefan Glienke Thanks, I'll look at that.
ReplyDeleteIt appears to have been moved to Bitbucket, BTW:
https://bitbucket.org/idursun/delphipi
(Is it me, or does it seem ironic that building it requires installing three external packages, first... :-D)
Christopher Burke Sorry, I missed your comment there.
ReplyDeleteIt's the "as long as the names and location are the same" that bothers me; that's the reason we use a different drive mapping for each project; then the location can stay the same. But I'd like to get rid of the drive mapping (we're running out of drive letters, for various reasons beyond our control).
Keeping a single repository with the library would fix that problem (check out the appropriate version when opening a specific project), but it would add additional overhead to keep track of the library versions for each project.
We've had enough trouble convincing everyone to switch to a different version control system that I'd rather not introduce extra policies or procedural hurdles... :-\
JCL is needed to not reinvent all the things regarding reading Delphi settings to start the compiling process and install the packages after.
ReplyDeleteVTV is needed for the GUI version of Delphi PI.
I don't remember what would be the third.
Since DelphiPI is not bootstrapped (i.e. compiled on the machine it installs things on) I don't see any reason why it should be self-contained.
Stefan Glienke Oh, I understand why they're necessary; it just struck me as ironic that a package manager requires external packages in order to build, is all. :-)
ReplyDeleteBTW, you are right, it only needs two libraries, not three.
Martijn Coppoolse The intent was to have library versions within each project repository (which is what I currently do). Not a repository dedicated to the libraries.
ReplyDeleteChristopher Burke How do you use registered components in different repositories, then? They're bound to be in different locations, no?
ReplyDeleteMartijn Coppoolse The local file location can be the same, even though they each have their own repository (per project).
ReplyDeleteSo you exit Delphi, check out your project - this checks out the project and the appropriate library versions (from the project repository) into the standard local location - restart Delphi. I have four parts to the project checked into the SVN repository - source (project source tree),build (project binaries),libs (3rd party libraries),installs (installs for 3rd party libraries). The local path for libs can be fixed (or even fixed per Delphi version if you want).
Christopher Burke Ah, I think I see what you mean.
ReplyDeleteBut AFAIK, it's not possible to check out files from the same repository to different locations in Mercurial (which is what we'll be using). Or perhaps it is, but I haven't yet come across that possibility. Will check if this is possible.
Because our projects are in different locations locally, whereas the component libraries need to be in the same location.