Hi,

I did a git pull of latest lazarus sources.

Someone added laz.virtualtreeview and fpdebuggerfp to the IDE uses clause.

This caused the compilation to fail, since these units are also in the installed packages.

For instance the online packagemanager also used laz.virtualtreeview, so laz.virtualtreeview was added to staticpackages.inc, which is included in the uses clause and leading to duplicate units in the uses clause.

If some functionality of the IDE uses laz.virtualtreeview then the IDE should properly list a depencency on that package, instead of adding it hardcoded in the IDE uses clause. As soon as a user installs the package in question (s)he will have the same error as I did.

I removed the duplicates and pushed the change.

Michael.

They werent duplicates.
Those units (or their packages) are now hardcoded included.

This error happens everytime, when packages become part of the core list. Because older IDE are not forward compatible with that sort of change.

With then removed, the IDE will fail to build, when those packages are not installed manually.

==========
To work around:

Build once via
? make clean bigide
and after that all should work.

Or remove the 3 units from lazarus.pp / rebuild / add them again

Once you have a new IDE, it wont add them to staticpackages anymore.

Is there no way to make the IDE forward compatible with that kind of change ?

OK. I will re-add them.

Maybe this should be documented somewhere, or some warning should be given on the mailing lists that this change has happened.

If I just do a git pull and have this problem, currently there is no way to know.

And if it happens again in 5 years, I will surely have forgotten this mail.

Michael.

[...] This error happens everytime, when packages become part of the core list. Because older IDE are not forward compatible with that sort of change.

As this happens seldom there is no detection built in (yet) to handle this automatically.

... or update lazbuild and use that to build the new IDE.

Mattias

If possible, might be a good idea.

And rather than hardcoding this in the uses clause of lazarus, I would think it is better to have a list of 'always-include' package names coded somewhere in the sources.

Then the 'hardcoded' packages are simply added to staticpackages.inc, and the IDE can warn when it is started after recompilation when an additional recompilation is needed:
It can then detect that the list of hardcoded packages has changed after compilation.

The problem is then simply non-existant.

As all naive users, I use 'Tools - Build lazarus'. Silly me...

Michael.

[...] > As this happens seldom there is no detection built in (yet) to > handle this automatically.

I added a simple detection, so in the future the IDE will not add base packages to staticpackages.inc.

I also added some comments.

Note that when a base package is renamed or a new one is added it will still need a clean build using make. To support these cases it would be needed to load the new lpk files, which requires error handling etc.
Another idea is to detect such changes, warn the user and build using make+lazbuild.

Mattias

Thank you !

I pulled you changes and rebuilt, all recompiles without issues. And the comments will definitely give a hint as how to proceed in case it still goes wrong...

Michael.

Afaik there are 2 scenarios.

1) The duplicate.
The user has the package installed, that now became a base package. So units are used twice.

For this there may be a very simple solution.
- staticpackes is used by lazarus.pp
- So we could add new core-packackage-units to a different unit's use clause. Then they don't appear twice in the same uses clause. E.g. we could add a unit LazCorePackages, and that just contains a uses clause.? It would be used first in the uses of lazarus.pp.

It may also be able to do some trickery with IFDEF. If core packages are in the lazarus.pp uses clause, appearing only after staticpackages, then there could be {$IF not
defined(symbol_from_new_core_unit)}.
Haven't tested that, don't know if it would actually work.

2) The "unit not found"
The user does not have the package installed, yet. Say when we added IdeDebugger package. This would have added units to the "core" uses clause.
But not only. Units of IdeDebugger are used throughout the entire IDE code. And if you do not have that package installed (and use an old IDE, that does not have it as core yet), then the package's path is not in the list of unit-search paths.
So you will get "unit not found" errors.
To rebuild, you must first install the package that will become core.

Not sure how an old IDE can learn about that.

(The point (2) does not happen with every package. If the package is just used, so it can register itself, then that will be fine.) E.g.
- LazDebuggerFpLldb => core, but only registration
- SynEdit => core, and units get used

It would not, because FPC loads the units only at the of the uses clause and not once for every unit it finds. This is an incompatibility with Delphi, but currently there's no real desire to change that as it only affects such uses-clause trickery. If it *would* work however you could simply do {$if not declared(name_of_the_unit)}, because the unit name is also a valid symbol.

Regards,
Sven

Sven Barth wrote

?If it *would* work however you could simply do {$if not declared(name_of_the_unit)}, because the unit name is also a valid symbol.

ooohh nooo. That would be like C header files.... Don't wont that. ;)

[...] Note that when a base package is renamed or a new one is added it will still need a clean build using make.

The IDE now detects such changes, warn the user and offers to build using make distclean, make lazbuild and lazbuild --build-ide=

Mattias

Martin Frb via lazarus schrieb am So., 19.
M?rz 2023, 20:57:

It's you who brought out the ifdef idea and I simply pointed out a more correct solution than picking some random symbol in the unit.

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230320/1646b43c/attachment.htm>