Vincent Parrett

Thanks. Only need the base config.. at the moment I'm only building the Release config, if users need to debug then there is the option to usesource when installing (adds the source to search paths, as it did before I implemented compilation). I'm using msxml already in the project as I prefer to use XPath for selecting nodes. I will take a look at this in the next few days. I'm migrating FinalBuilder 9 dev over to using DPM (for non visual libs for now) so I'm dogfooding as I develop.

I do, but there's always a chance to learn from others and improve my code 😉

Definitely interested. I have code already in DPM for reading values from the dproj (dealing with the awful config inheritance setup) but not for writing... the code is a hacked version of what we have in FinalBuilder, which is far from perfect.

I know how to make it compile, just pointing out that the project no longer compiles as checked out from svn (it usually does).

@pyscripter I'm just pointing out that this bug is not isolated, but is a symptom of an endemic issue with vcl styles in general. I'll leave it at that.

This whole saga is typical of the VCL Styles support - in short, it's a mess. My guess is they really don't have anyone inhouse that is an expert with this stuff, so various people (contractors?) tinker with individual issues without an overall picture of things and with an impact analysis. You only have to look at how double buffering is handled 15 different ways in the vcl for various controls. Then there's the overpainting that happens when controls are resized (the whole form is repainted for each control). https://quality.embarcadero.com/browse/RSP-30639 And the response to it has been laughable at best. They "fixed" the design issue by tinkering with one affected control (TMemo) but left the rest (citing the need for interface changes) - but now they expect us to enter separate issues for each affected control! I suspect that is so they can split the tasks up to different people... so we can get more of the same tinkering. Seriously, if you are not already using VCL Styles, then don't bother with it.

Scoped Unit Names issues pretty much made me decide to make XE2 the minimum version I will support in my open source projects. Even then, I still have issues every day so I typically run a build in every version to at least see if it compiles.. it's so easy to break things for different compiler versions without realising! The next update to DUnitX and Delphi-Mocks will drop < XE2 support. TBH, I think we are doing the community a disservice by supporting very old (pre XE2) versions of delphi in libraries.. if we want delphi to continue we need people to upgrade occasionally!

So what should the standard reaction be? I code my custom controls using my own double buffering and ignore the vcl's double buffering, which tends to be rather buggy and variable (different implementations of it throughout the vcl) - especially when vcl themes are enabled.

I'm seeing similar issues [dcc32 Fatal Error] FinalBuilder9.dpr(292): F2084 Internal Error: AV0D8C3340(0D8A0000)-R00000018-0 Steps, run under debugger, step a while, terminate process (Ctrl+F2) Run. [dcc32 Fatal Error] VSoft.IDE.WelcomePage.pas(959): F2084 Internal Error: I4025 Steps, run under the debugger, step, debug\evaluate, check a classname prop, terminate Modify Code Run. Build and then run works after this.

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

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

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.

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

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.

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.

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?

I tried building GExperts for 10.4 from source but svn appears to be missing a file I:\GExperts\source\framework\GX_UnitExportsParser.pas(13): error F2613: Unit 'GX_UnitExportList' not found. [I:\GExpert s\Projects\DelphiXx104\GExpertsRS104.dproj] This is after running svn update.