[Lazarus] Lazarus Release Candidate 1 of 1.4

[Mattias Gaertner]

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.


> 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?


> The second solution would avoid unnecessary recompilations, e.g. when 
> the custom version uses a different WS.

Most packages have $(LCLWidgetType) in their output directory.

> In the current situation almost 
> all packages appear to require compilation at every build, because 
> compiler options in the lazarus tree are different from current options, 
> while most of them actually do not.

1.4RC1 on Linux had a bug about comparing the -Cg
option in Makefile.compiled. That had been fixed.
Hopefully in 1.6 we have replaced Makefiles with fpmake.


Mattias