Is *.lfm duplication in lib dir necessary? Bug or feature?

[avra]

When compiling some packages that contain *.lfm files Lazarus copies these files to lib dir (something like lib\$(TargetCPU)-$(TargetOS)-$(LCLWidgetType)) and after IDE rebuilding everything seams to be fine at first, but after installing some other packages you can see that during each new IDE rebuild Lazarus will complain that there are *.lfm duplicates.

Is this bug or a "feature"? How can I prevent this?

I am investigating my options for lowering the number of duplicates in my IDE in order to prevent "incompatible ppu" errors mentioned in this thread. While I can see various ways to solve *.ppu duplicates, I am having trouble solving *.lfm duplicates.

If you want to see *.lfm duplicates then for example you can simply install PascalSCADA from OPM. On first IDE build everything is fine, but on all later builds you can see warnings like this:

...
Warning: Duplicate file "ustructuremapper.lfm" in "pascalscada_common 0.7.5", path="C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\lib\i386-win32-win32\ustructuremapper.lfm"
Warning: Duplicate file "ustructuremapper.lfm" in "pascalscada 0.7.5", path="C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\src\scada\ustructuremapper.lfm"
Warning: Duplicate file "uwesttagbuilder.lfm" in "pascalscada_common 0.7.5", path="C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\lib\i386-win32-win32\uwesttagbuilder.lfm"
Warning: Duplicate file "uwesttagbuilder.lfm" in "pascalscada 0.7.5", path="C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\src\scada\uwesttagbuilder.lfm"
...

Btw, I can also see there some "orphaned ppu" warnings which I do not quite understand, so sharing some light on that would also be helpful:

...
Note: Duplicate unit "westasciitagassistant" in "pascalscada_common 0.7.5", orphaned ppu "C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\lib\i386-win32-win32\westasciitagassistant.ppu"
Note: Duplicate unit "westasciitagassistant" in "pascalscada 0.7.5", ppu="C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\lib\i386-win32-win32\westasciitagassistant.ppu", source="C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\src\scada\westasciitagassistant.pas"
Note: Duplicate unit "westasciidriver" in "pascalscada_common 0.7.5", orphaned ppu "C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\lib\i386-win32-win32\westasciidriver.ppu"
Note: Duplicate unit "westasciidriver" in "pascalscada 0.7.5", ppu="C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\lib\i386-win32-win32\westasciidriver.ppu", source="C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\PascalSCADA\src\scada\westasciidriver.pas"
...

I checked and for example there is no duplicate westasciidriver ppu or pas file. Unlike reported warning.

[Martin_fr]

It seems that the 2 packages pascalscada and pascalscada_common have some custom path settings and share one lib directory for all there ppu (and copied lfm).

In general: Playing with path settings, is the quickest way to disaster. (Yes of course, it can be done correct. But "abuses" like this seem to be a regular issue)

About "orphaned ppu"  / Not tested, but either as follows or very similar.
abandoned vs duplicate probably depends on a unit being in the package that is compiled first or second.
Lets say both units together have only unique files. So no package overrides the files of the other.

One package (probably the 1st to compile) provides the westasciitagassistant.ppu and writes it to the lib folder.
The other package, sees that westasciitagassistant.ppu exists, but it has no pas file for it, so it is abandoned.

My guess is the duplicate happens if the 2nd package wants to put the ppu into the lib folder (in case no "clean all". The IDE checks the lib folder of *ALL* other packages for a unit of the same name. Since the first package points to the same folder, the existing ppu (which will be overriden by the 2nd package) appears to be in the first package too. The IDE does not realize (I guess) it is the same folder.

I guess the lfm can be explained in a similar way. They appear to exist in both packages, but should be in one only.

[avra]

My guess is the duplicate happens if the 2nd package wants to put the ppu into the lib folder (in case no "clean all". The IDE checks the lib folder of *ALL* other packages for a unit of the same name. Since the first package points to the same folder, the existing ppu (which will be overiden by the 2nd package) appears to be in the first package too. The IDE does not realize (I guess) it is the same folder.

Shouldn't that be filed as a bug in bugtracker?

I have read what you wrote several times but I still have trouble to digest all of what you said. My knowledge on the topic is too thin to understand it properly. Unfortunately I still don't get it what should be done to improve that specific package.

[Martin_fr]

I see it as a missing feature.
That is if I am right. I have not tested my theory. It is just what I expect from the bits of knowledge I have.

I do not have PascalScada installed.
1)
Are the 2 packages .lpk files in different folders (maybe, one in a subfolder of the other?), or in the same folder?
2)
Can you check in the package options dialog: Compiler Options / Paths
The entry for "Unit output directory (-FU)" for each package, does it (once fully resolved) point to the same directory?


Here is my theory again
Packages P1 and P2 both store their ppu in c:\common\

P1 has a unit foo.
P1 is compiled first.
Now  c:\common\foo.ppu  exists.
When P2 is compiled, it does see foo.ppu in its output path. But P2 does not have foo.pas. So P2 thinks the unit's ppu is abandoned.


Also when checking for duplicates, the IDE goes (afaik) through each package's output dir, and gets all ppu.
So the IDE checks c:\common\ for P1.
Then the IDE checks c:\common\ for P2 => duplicate ppu are found.
However this may depend on the order of compilation.
- My GUESS is, that before compiling a package, the output of each required other package is checked, and compared to the pas files of the current unit.
=> If you re-build, without cleaning, and maybe only then, the output of P1 contains all the ppu of P2. So when P2 rebuilds, it does see its own ppu, but believes they belong to P1.