wow, some pretty heated discussion.

personally, i do not make use of any of the packages available in this 'OPM' thing, nor do i ever install additional visual components into the Lazarus IDE. the reason: i usually find code written by others is a poor fit for my requirements, being either: excessively complicated, or, packed full of superfluous features (thereby creating excessive complexity), or, simply buggy.

having said this, surely the whole idea of a programming language is that it (a) complies with a well documented standard, and, (b) incorporates rigorous backwards compatibility. i would desperately hope that anything written five or ten years ago using Lazarus (FPC+LCL) would be buildable - with an absolute minimal of tinkering - using today's release of Lazarus and FPC.

if there is so much source code residing in this 'OPM' that no longer compiles and/or works, where has everyone gone wrong?! have portions of the Pascal Language been deprecated? has the syntax changed? or are programmers submitting code that is hardware- or OS-specific?

cheers,
rob :-)

robert rozee wrote

if there is so much source code residing in this 'OPM' that no longer compiles and/or works, where has everyone gone wrong?! have portions of the Pascal Language been deprecated? has the syntax changed? or are programmers submitting code that is hardware- or OS-specific?

Over the years, API changes to the LCL (usually for Delphi compatibility) have been the main changes that have broken my code.

Tony Whyman via lazarus kirjoitti 19.3.2026 klo 14.39:

Yes, that is one reason.

Another reason is that the libraries are refactored to reduce wrong dependencies. Simple utility functions used to be part of LCL, for example in unit LCLProc. They were moved to other units and package (eg. LazUtils) to break the dependency.

Sometimes a whole unit is cleaned from unwanted dependencies and then moved elsewhere.

Just yesterday I did a big refactoring and removed LCL dependency from code dealing with macros and path configuration. A simple unit test program reading a project's paths would have needed LCL and the NoGUI widgetset hack. This time the refactoring didn't affect any public interface units.?Testing will continue today.?For details see :

https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/624

LazBuild is a warning example of those wrong dependencies. It is a command line program but it pulls in most of Lazarus IDE internals and LCL as dependencies. The ugly NoGUI?widgetset hack was created for it, causing many problems.

I have been guilty for many of the breakages in backwards compatibility but they are done in a controlled way. The old function or unit is first marked as deprecated and deleted only in the next major release. It means a well maintained project can easily keep up by reading "deprecated" messages and acting accordingly. A 5 year old project may not compile but then you can "Search in Files" the missing piece and add a unit in uses section.

This is quite?necessary because the design is not perfect and the dependencies are a mess. Without any refactoring the problem typically gets worse. Please note that most good quality code does such refactorings sometimes. For example QT lib which has a good design AFAIK, restructured their code to reduce dependencies between its modules.

Anyway, Lazarus internals will change also in the future. It means that OPM should have *only* maintained packages. Otherwise it will become a junkyard.

Regards, Juha

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260320/32061c9b/attachment.htm>