timfrost

I regret to say that as a library consumer I agree with Stephan Glienke on this. Instead of a package manager I already have an excellent tool to control all the third-party Delphi libraries we use. It's called FinalBuilder(!), and it does everything I need to build these libraries (and a few of our own) from source, and install all the design packages. This ensures that the source/DCU/BPL/DCP files are all where I expect them to be, not scattered around my drives at the whim of a third-party developer. There is a set procedure I follow for new Delphi versions, and a simple set of changes to make to a cloned copy of the Finalbuilder target for a new compiler and a new main folder of our Delphi source and library folders. For library upgrades, I never install a new library automatically into a production environment (so I will never use a "package manager"). Instead I install the source elsewhere, and first review all the changes with Beyond Compare (and apply our few source changes and fixes if still needed), before allowing them near the production development environment. I find from long experience that this the best way to eliminate surprises on upgrades. Separate targets in Finalbuilder can be conditioned to continue building with the old version, with perhaps older library versions also, while testing the new one. There are a couple of annoying third-party library installers we use, where it is impossible to turn off the 'build' process after install. For these I keep an old VM where I can run the installer, then move the source so that I can control the installation with our FinalBuilder project. For a few .Net applications we have needed, I have used Nuget for third-party libraries. Yes, the source and solution files get installed, and it is possible to modify source if needed (for each upgrade). But that is only possible, I believe, because the development environment has been designed, and Nuget integrated, to make this simple. Nobody could make that claim for Delphi, and that is why having a Finalbuilder project to do all this makes it so simple. I congratulate Vincent for having the vision to try to solve the packages issue for Delphi, but sadly I have to hope that it takes a long time before third-party vendors take it up and try to force me to use it! I do concede, however, that a feature like this would certainly help and encourage new users, and perhaps large teams, to make use of third-party libraries; but for sites with mature applications with a good number of libraries, and who need to manage changes carefully, I can only see new problems.

I found this as: https://quality.embarcadero.com/browse/RSP-23655 I suggest you vote for it (as I have)

And perhaps one more (though tiny): The very useful Warn Directive tool misses at least one warning. I found that COMBINING_SIGNED_UNSIGNED64 (1073) is absent. It might also be useful to have an option in the dialog to show the warning numbers (and perhaps sort on this value). I find that some numbered warnings have a descriptions which does not match the the name, making them hard to find in the list. For example the compiler reports "W1036 Variable 'x' might not have been initialized", but needs USED_BEFORE_DEF to suppress this.

If making a mistake is not critical, just choose any of these algorithms; without knowing the context, and without detecting the language of the surrounding text, they seem about equally risky to me. If you are transferring money, or worse, measuring dosage of medicines, then none of them are of any practical use.