kryslt / KControls

Free components for Delphi and Lazarus, this is the main repository maintained by the original author.
BSD 3-Clause Clear License
59 stars 32 forks source link

Path error #54

Closed arlantsev52 closed 6 months ago

arlantsev52 commented 6 months ago

An error occurs during installation due to the fact that the files KcontrolsDesign, k picture editor .. are not located in the lazarus folder

kryslt commented 6 months ago

Which bug? I don't see any problem. All paths are relative and correct in packages\lazarus\kcontrolslaz.lpk. Maybe you use some old version of Lazarus?

martok commented 6 months ago

I had the same issue updating after the directory changes. I don't fully remember what I did to fix it, but it involved multiple iterations of uninstalling both the designtime and runtime packages (first one, then the other, not at the same time) and cleaning the object and generated files.

The paths in the repo are correct, but somehow Lazarus didn't pick them up just from recompiling the packages. There was something like a "ghost" package with the wrong paths left behind that would get included instead of the real, updated, one.

kryslt commented 6 months ago

I had the same issue updating after the directory changes.

Did you install/update via repo clone or via online package manager?

martok commented 6 months ago

Did you install/update via repo clone or via online package manager?

Repo.

I knew that the paths had changed, so I thought I could just remove the packages via Packages\Installed Packages, rebuild the IDE and then reinstall, but that ended up using the search paths from the old kcontrolslaz (which didn't even exist anymore?). This also ended up generating basically empty .pas files for the packages, I think the IDE may have had the cached state and new state at the same time and got really confused when the files weren't there.

In the end I did something along the lines of remove kcontrolslaz, rebuild IDE, remove kcontrolsbase, rebuild IDE, reset all auto-generated files (git clean -dfx), rebuild the IDE again for good measure, and then install normally.

kryslt commented 6 months ago

In the end I did something along the lines of remove kcontrolslaz, rebuild IDE, remove kcontrolsbase, rebuild IDE, reset all auto-generated files (git clean -dfx), rebuild the IDE again for good measure, and then install normally.

Very strange. I didn't have such problems. After I changed the directory structure, I ran Lazarus and it reported the broken package: Clipboard01 I just opened the package with Package/Open package file (*.lpk), then compiled it normally (or maybe ran Recompile clean) and then installed without issue. It's also worth noting that I'm not using the official Lazarus installer. I use the fpcupdeluxe build everywhere on Win, Linux, Mac (now some trunk snapshot v3.99). So it's also possible that there was a bug in Lazarus and it was already fixed in the trunk.

Either way, without a description of the specific error message, I can't look for more, so I'm leaving it open.

martok commented 6 months ago

Very strange. I didn't have such problems. After I changed the directory structure, I ran Lazarus and it reported the broken package:

Yep, same here, but getting rid of that broken dummy package wasn't super easy.

I use the fpcupdeluxe build everywhere on Win, Linux, Mac (now some trunk snapshot v3.99).

Same here, been on trunk since 2012 or something. And with that reminder, I built a new snapshot and oh hey, the exact same configuration and files that built fine in March now fail. Having the file path correctly in the package lets the IDE open the file, but the compiler still doesn't find it. That required also adding the search path.

diff --git a/packages/lazarus/kcontrolslaz.lpk b/packages/lazarus/kcontrolslaz.lpk
index 11500cd..bfa750d 100644
--- a/packages/lazarus/kcontrolslaz.lpk
+++ b/packages/lazarus/kcontrolslaz.lpk
       <PathDelim Value="\"/>
       <SearchPaths>
         <IncludeFiles Value="..\..\source"/>
-        <OtherUnitFiles Value="..\..\source"/>
+        <OtherUnitFiles Value="..\..\source;.."/>
         <UnitOutputDirectory Value="lib\$(TargetCPU)-$(TargetOS)"/>
       </SearchPaths>
       <Parsing>

Maybe that's what @arlantsev52 is actually reporting? In that case, sorry about the noise...

kryslt commented 6 months ago

That required also adding the search path.

This is really strange. No such change should be necessary and I did not need to do that anywhere. The relative paths in the Files section should be enough for the compiler to locate the files. The other paths (-Fi, -Fu) are only used to inform the compiler about the path to the KControls.inc file or other *.pas files that would not be listed in the Files section.

martok commented 6 months ago

No such change should be necessary and I did not need to do that anywhere.

Strange indeed...

The relative paths in the Files section should be enough for the compiler to locate the files. The other paths (-Fi, -Fu) are only used to inform the compiler about the path to the KControls.inc file or other *.pas files that would not be listed in the Files section.

... because this is not how it works. The relative file paths in the LPK/LPI are just for the IDE and not given to the compiler at all (which is why Ctrl-Click works even if the compiler complains). The compiler only gets the main file (the generated ${packagename}.pas), the package's own search paths as -Fu and the PPU/O paths of all (recursive) required packages as -Fu (see Package Settings -> Show Parameters).

When youre adding a file in a location that isn't already covered by the current search paths, the IDE even helpfully suggests adding the new path. As a test, removed kcontrolsdesign.pas and re-added it (Add->File from Filesystem):

Does exactly what I did manually. What really surprises me though: why did that work before. I checked the repo before updating the IDE, and I had made no such change in March. Maybe there was another path left from the dummy package...

kryslt commented 6 months ago

... because this is not how it works.

Yep - you are right. I always thought the different way about it. The question is why it worked for me all the time. I ran the Package KControlsLaz/Compiler Options/Test command and it produced (among others):

WARNING: orphaned file found: D:\Data\Delphi\KControls\packages\lazarus\lib\x86_64-win64\kcontrolsdesign.o
WARNING: orphaned file found: D:\Data\Delphi\KControls\packages\lazarus\lib\x86_64-win64\kcontrolsdesign.ppu
WARNING: orphaned file found: D:\Data\Delphi\KControls\packages\lazarus\lib\x86_64-win64\kpictureeditor.o
WARNING: orphaned file found: D:\Data\Delphi\KControls\packages\lazarus\lib\x86_64-win64\kpictureeditor.ppu

Then I ran Package KControlsLaz/Recompile Clean and it already reported:

kcontrolslaz.pas(12,46) Error: Cannot find kcontrolsdesign used by KControlsLaz. Check search path of package KControlsLaz, try a clean rebuild, check implementation uses sections..

Adding the path ..\ to the -Fu section really fixes this.

The question is why I didn't get this error message earlier, as I'm sure I ran the Recompile Clean command earlier. Unfortunately, I won't find out now. In any case, this is really a bug in the package settings, which will be fixed by adding that path.