Vincent Parrett

How do you manage upgrading libraries. Once you upgrade for one project, you have to upgrade for every project, that's the nature of global libraries. The "overhead" of installing packages is really quite small, and you can do it incrementally. DPM does not use the library path, but that doesn't mean you still cant. FWIW, one of my reasons for working on dpm is probably somewhat selfish, but 90% of the problems FinalBuilder customers have with compiling delphi projects are related to the library path. I'm hoping that dpm will provide a standard way to work with libraries, so the whole issue of compiles on one machine, not on the other becomes a thing of the past (I can spend my time working on other things!). There are other benefit to not using the library path is the compiler doesn't have to trawl through every installed library even when the project doesn't use them, which makes for slower compile times. It's early days, there's still a lot to do on the project, including IDE integration, which will make working with it a lot simpler. Stay tuned.

Thanks Packages are downloaded and extracted into a package cache folder, which is configurable, and then added to the search path of the project. I have no plans for using the global library path. Packing the whole project with deps - not planned. Delphinus is very different to DPM so not sure how that would work. Installing from a repo.. maybe, but would need to figure out versioning. Not planning to look at this any time soon, but if someone wants to contribute I'm open to it.

On windows 10, this may be a permissions issue. Applications that were launched elevated are not visible to applications that are not elevated.

If you run them without TestInsight do they complete OK? Also if you are using the version of DUnitX that shipped with delphi Berlin then I'd recommend grabbing the latest from github to test with. https://github.com/vsoftTechnologies/dunitx

Digitally signing the installers and binaries may help, but we do that and still get the occasional false positive. We submit the false positive report and it typically resolves itself in a few days (except for windows defender, that takes ages).

I think it was done because every contributor was editing in a different version of delphi, which then changed the dproj file and broke it for older versions.

The GUI projects have issues, I don't use them and haven't worked on them.. not sure when they broke but will try at least the fix the VCL one. FWIW, the console tests project and the console examples project both compile and run fine. You really don't need a gui to run unit tests, except when developing, and for that I use TestInsight.

Memory leak reporting in delphi unit tests are difficult to do accurately, as the test framework is using the same memory manager as the tests. Not sure who this is aimed at "Anyway the devs seem not using test project at all, it is even not compilable in current state." but I can assure you as a dev on DUnitX and many other projects I use unit testing every day. There is some debris in the dunix repo, mostly in the fmx area due to the lack of compatibility between fmx versions (and I don't use or work on fmx stuff). It's not easy to keep everything in a compiling state for a ton of different delphi versions, especially when I don't have every version installed.

300Kb might not sound like much, but when it's part of a 3.1MB page (this page) and 66 requests each with 350ms latency (I'm in Australia), then it does matter. I remember posting about this before, nothing has changed, these forums are still really slow for me. Functionally they are fine, quite usable, but they could definitely use some optimisation, like combining/bundling js files so that less requests are made. This alone would be a major improvement.

I guess the project wizard needs some work. I'll try and schedule some time but have a pretty full plate right now.

The readme is a bit out of date, embarcadero did contribute some changes to make it work on mobile and linux.

Thanks, didn't get the automated one, but go the one you sent shortly after your reply.

How do existing users get this?

https://www.finalbuilder.com/resources/blogs/managing-delphi-version-info-with-finalbuilder

Most likely, but IANAL.

"One time" so I get to install one more time and then I'm up shit creek?

AFAIK there's no way to deactivate or deregister an install.

WTF Embarcadero, you are just alienating the few paying customers you have left. If you use activation as a licensing mechanism, you MUST offer deactivation or a means to move licenses, without requiring support involvement. Seriously pissed off by this move, the cow is almost milked dry!

Delphi/Rad Studio desperately needs a proper package/library/component manager. A package manager provides a standardized way of consuming third party libraries. At the moment, use of third party libraries is very much adhoc, and in many cases this makes it difficult to move projects between machines, or to get a new hire up and running quickly. Other development eco systems, like Ruby, .net and Javascript, recognised and solved this problem many years ago. Getting a Ruby, .net or Javascript project up an running, in a new working folder or new machine is trivial. Delphi Package Manager RFC

@timfrost Thanks for your feedback. Funnily enough, I do exactly what you do with my array of third party packages right now, but it's not really optimal (even with a great tool like FinalBuilder 😉 ). Taking updates to packages is still problematic/manual and error prone, and this is really still a global thing rather than per project. I want to open a project in the IDE, and know that all my dependencies are present and correct, just we do now with nuget. As you would expect from a company that sells a CI Server, we do lots of CI builds, and building all the third party code from source with every build is painful to say the least, it almost doubles our build times. Building them once on install would speed up the build process dramatically. Of course there will still be the option to just use the source, and an option to turn off compilation on install. Authors/Vendors will have the option to choose what they distribute, source code, pre-compiled binaries or both, the option to compile on install (which users can override). This project is going to take some time, there are so many variables, every author/vendor does things differently, so we'll need to consider all the variables and come up with something that hopefully works for the majority. I don't have the power to force this on anyone, nor would I want to. I'm just trying to create some order out of the current random chaos that exists now.

@Stefan Glienke weren't you working on something like that? That is something I'd pay for!

@Stefan Glienke It's shame you feel that way, I was thinking the spring framework would be a perfect candidate for something like this, and in fact I've been using it while playing with ideas for the package specification. Yes, design time package unloading will be a problem, most likely what we'll do is on package restore, if there is any change in the design time components installed we'll offer to restart the IDE. Of course this is not an issue for command line or CI builds, as we don't need to install components, just ensure the project can be built with the correct search paths. This project will have lots of technical hurdles, but I still think we can do better than what we have now.

@Remy Lebeau That does still work, however it still doesn't allow you to install multiple versions of the same package, which makes life difficult. For example, on v7 I might use packageA.1.0.0 and on v8 I might use packageA2.2.0 - I don't want to update v7 to use the newer packageA, for a bunch of possible reasons. There are (as others have pointed out) problems with unloading packages, lots of third party packages don't clean up properly and unloading causes IDE instability.

@Thijs van Dien In my experience the signing feature in Innosetup was fragile, mostly because if the timestamping failed (due to the server not responding, happens a lot) then you had to recompile the whole thing again. Better to do the signing and timestamping seperate from the innosetup step (using signtool), and the signing and timestamping separately so you can retry when timestamping fails.

If you also timestamp the signature, the exe will be signed permanently. If you skip timestamping the signature will no longer be valid once the certificate expires. This blog post covers codesigning & timestamping