[re-opened] Package PPU location question (fallback output directory?)

[CCRDude]

I've moved code out into separate packages. Mostly works fine, but ...

Both in the IDE and when using lazbuild, I sometimes get an error that a certain file could not be found. Here's some excert from the build log:

https://wiki.freepascal.org/lazbuild
Info: (lazarus) Open dependency Project: PROJECTNAME uses PACKAGENAME ...
Info: (lazarus) Open dependency: trying "PACKAGENAME" in 2 links: "D:\Development\Packages\PACKAGENAME\PACKAGENAME.lpk" ...
Info: (lazarus) Open dependency: package file found: "D:\Development\Packages\PACKAGENAME\PACKAGENAME.lpk". Parsing lpk ...
Info: (lazarus) Open dependency [PACKAGENAME]: Success: "D:\Development\Packages\PACKAGENAME\PACKAGENAME.lpk"
...
Hint: (lazarus) Missing state file of PACKAGENAME 3.10.2: D:\Development\Packages\PACKAGENAME\lib\i386-win32-package\PACKAGENAME.compiled
Hint: (lazarus) Fallback output directory of PACKAGENAME: D:\laz\config_lazarus\lib\PACKAGENAME\lib\i386-win32-package
...
(10001) PPU Loading D:\Development\Packages\PACKAGENAME\lib\i386-win32-package\SOMEUNIT.ppu
(10011) PPU Source: SOMEUNIT.pas not found
(10028) Recompiling SOMEUNIT, checksum changed for D:\Development\Packages\PROJECTNAME\lib\i386-win32-package\FORMUNIT.ppu {impl}
Fatal: (10022) Can't find unit SOMEUNIT used by FORMUNIT
Fatal: (1018) Compilation aborted
Error: D:\laz\fpc\bin\i386-win32\ppc386.exe returned an error exitcode
Error: (lazarus) Compile Project, Mode: Release-x86, Target: d:\Development\Projects\PROJECT\bin\PROJECT-Release\PROJECTNAME.exe: stopped with exit code 1
Info: (lazarus) [TCompiler.Compile] end
Error: (lazbuild) failed compiling of project d:\Development\Projects\PROJECT\source\PROJECT\PROJECTNAME.lpi

Doing "Cleanup and build" in the IDE works, but I have a PowerShell script compiling all modules in 32 and 64 bit and creating installer, portable edition, &c., so getting this to work with lazbuild would be great.

What is the issue with the "fallback output directory", might this be causing ppu conflicts? D:\laz\config_lazarus\lib\ does not even exist.

Here's the simply PowerShell module I use to build using lazbuild.

Code: [Select]

Import-Module PepiLog

$global:LazarusPath = "d:\laz\lazarus\"
$global:LazarusBuildExecutable = "d:\laz\lazarus\lazbuild.exe"

function Invoke-BuildLazarusProject {
  Param([string]$AProjectFilename, [string]$ABuildMode, [string]$ALogFile)

  & $global:LazarusBuildExecutable ("-B") ("-r") ("--verbose") ("--verbose-pkgsearch") ("--build-mode=" + $ABuildMode) ($AProjectFilename) > $ALogFile
  if ($LastExitCode -ne 0)
  { 
    return $false
    Write-LogError ("lazbuild: " + $sProject)
  }
  else
  {
    return $true
  }
}

I can't find anything missing in the documented lazbuild parameters, but it seems there is some kind of issue with the package recompilation.

[CCRDude]

A fresh Lazarus installation solved this issue. No idea where something cached has caused this issue

[CCRDude]

Issue now appearing in the Lazarus IDE (trunk) as well. Did a completely new installation (not just overwriting existing, but starting fresh).

I've tried adding -Ur to the package, since fpcupdeluxe needed this as well now with a similar bug.

Inside the Lazarus IDE, the messages are similar:

Verbose: Compiling PROJECTNAME.lpr
Verbose: PPU Loading D:\Development\Packages\PACKAGENAME\lib\i386-win32-package\SOMEUNIT.ppu
Verbose: PPU Source: SOMEUNIT.pas not available
Warning: Recompiling SOMEUNIT, checksum changed for D:\Development\Packages\PACKAGENAME\lib\i386-win32-package\SOMEUNIT.ppu
Fatal: Can't find unit SOMEUNIT used by PACKAGENAME
Verbose: Compilation aborted

Of course, the unit exists (I even tried changing names), and the package compiles fine.

But the project now doesn't compile at all because of the above.

[CCRDude]

There's some useful information in this thread.

There is a 3rd known way for this error. But it (probably) does not apply here.
The error can happen with 2 files in the same package. If the have circular references, and use inline in a very specific way.
They will both be build, but later one of them will give this error. (At least that was possible with older fpc)

I was actually able to solve the issue by changing the circular dependency in said unit. Then it occured with another unit, where again I moved the dependency from interface to implementation, and simply checked the type of the now more generic parameter.

[marcov]

The problem is that if a files moves package, stale builded files from previous builds might not be  cleaned out anymore.

I usually first try to micro manage by  removing .o and .ppu from packages where the units have been removed. Only a quick attempt, no night work.

Because if that fails I delete all of them and then rebuild IDE and projects. Since that costs about a minute, you can't spend more than a minute manually fixing anyway.

[CCRDude]

I regularly simply delete my "lib/" folders to avoid that. I might go through it again, since I seem to remember that lazbuild stored ppu files in a different place than the IDE.  But it's not the cause here.

I did a few file search session across both disks multiple times this time, since that was my first assumption as well. Even installed Everything (Windows) to have a live filename index to speed up searches.

It's definitively not old .o or .ppu (if it was, changing the circular dependency wouldn't have helped).

Just had the third file to be reported this way, and removing the circular dependency helped to compile again.