[Lazarus] Lazarus Release Candidate 1 of 1.4

[Giuliano Colla]

Il 20/02/2015 01:32, Mattias Gaertner ha scritto:
> On Fri, 20 Feb 2015 00:23:57 +0100
> Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:
>
>> [...]
>> After some further analysis, I'm becoming convinced that clean all would
>> be unnecessary,
> There are always cases when a clean all is needed.
> For example when an unit is moved to another package. The compiler
> options are exactly the same, but you have to delete the old
> ppu files.
>
Let's say, would be less necessary.
>> it clean auto didn't have a flaw in how package
>> compilation is handled in TLazPackageGraph.
>>
>> In a situation where lazarus tree is not writeable, and a different user
>> path must be used, what happens currently is:
>>
>>   1. TLazPackageGraph.CheckIfCurPkgOutDirNeedsCompile checks from lazarus
>>      tree if the compilation is required.
>>   2. If yes, it verifies if normal output dir is writeable. The check
>>      fails, and it uses the FallBackOutputDir with SetDirectoryOverride.
>>      Compilation output goes in the user path, and overwrites possible
>>      old ppu's and resources. That's OK.
>>   3. If no compilation is required, compilation is skipped, and anything
>>      leftover in the user path remains untouched. That's the flaw.
> What exactly is flawed?
>
>
>>   4. When linking user path takes precedence over lazarus tree path
>>      (newly compiled must take precedence over old ones), and invalid
>>      leftovers abort the linking.
>>
>> The issue can be solved by brute force, always forcing the compile when
>> normal output dir is not writeable, or with more elegance, by checking
>> also the fall back output dir before deciding if a new compilation is
>> required.
> Do you mean line 3237?
>

I rather mean line 3206.
If normal output directory (i.e. the not writeable one, in our case) 
doesn't need compile, no check is made on the fall back directory.
If the fall back directory is empty (as it would be on a first time 
build) , a useless compilation is avoided, and this is Ok, but if it 
contains old ppu's  (as it may happen after an update) the old ppu's are 
left in place, and will cause linking to abort.

I'll make some tests on the transition from 1.2.6 to 1.4RC1 which shows 
the problem, to see if some smarter checks on PackageSytem can help, or 
if, after all, a clean all is the only viable solution.

Are there cases where a package units directory contains units from more 
than one package?


Giuliano