Vincent Parrett

This post covers manifest files with delphi. https://www.finalbuilder.com/resources/blogs/windows-manifest-files

It suffers the same issues as FixInsight.. a lot of noise produced too. Bothe FixInsight and Pascal Analyser both do a good job of finding simple things and enforcing best practice but they don't do flow analysis. https://blog.sonarsource.com/kill-the-noise-to-change-gear-in-our-code-analyzers Something like SonarQube would be good, there is a delphi plugin, this appears to be the most up to date fork - https://github.com/JAM-Software/SonarDelphi - it doesn't do flow analysis either (like the built in language support in sonarqube does for C# etc). Note I haven't tried it (yet), just peeked at the source code.

Thanks. It's taking shape quite nicely now.. still plenty to do, but I hope to have a fully working release this year. Once I get the design time stuff working I'll ping you to give it a try with your libraries.

I like this plan. I ran FixInsight over the code and there are lots of opportunities to clean up the code. Unfortunately fixinsight also produces a lot of 'noise' because there are lots of empty virtual methods which appear to be for c++builder support (no abstract support in c++ builder?) - but it's still a worthwhile exercise. I look forward to the day I can install Delphi, chose not to install the bundled Indy and install Indy via DPM, choosing which particular version I want, and not having to modify my projects as Libsuffix will be set on the packages 😉

Umm.... probably not

Umm.. Getit solves very little of anything I'm afraid.

https://www.finalbuilder.com/resources/blogs/dpm-package-manager-progress-update

LIBSUFFIX doesn't affect the dcp file names, only the bpl. I have to say that I wish Embarcadero were not shipping Indy so intertwined with the product. Pretty much the first thing I do when installing Delphi is remove all traces of Indy so that I can install my own version (usually later than the one they ship).

If the library is just a simple few pas files and doesn't have any design time components then yes, packages are not needed. That said, there are still benefits to providing packages, as it allows the libraries to be compiled and you can then just reference the compiled library files (dcu's) instead of compiling the library every time you build. I recently implemented this in my package manager project and it cut the build time (for 12 delphi versions) from 13 minutes down to 1 or 2 minutes for the package manager projects (command line tool plus ide plugins).

Well I am talking mostly about packages in the post, so in that context it makes sense. Relative paths are fine, until one of the files moves around. I had that issue yesterday with a well known third party package that wouldn't compile.. the relative paths on the includes were wrong.

Agreed, that's what gave me the idea to write the post 😉

Yes, I forgot about that feature. I have updated the post to mention it.

https://www.finalbuilder.com/resources/blogs/advice-for-delphi-library-authors

Never mind, I deleted my local copy an checked out again, and it builds fine. No idea why as svn wasn't showing any changes to the source (apart from GXIcons.res which happens during the build).

I just used the build script, which has worked fine for me until this error recently (a few weeks ago I think). The file is there in my local copy too.. so must be a path issue?