[Lazarus] Lazarus Release Candidate 1 of 1.4

[Giuliano Colla]

Il 19/02/2015 14:10, Mattias Gaertner ha scritto:
> On Thu, 19 Feb 2015 13:44:03 +0100
> Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:
>
>> Il 19/02/2015 12:32, Juha Manninen ha scritto:
>>> On Thu, Feb 19, 2015 at 1:10 PM, Giuliano Colla
>>> <giuliano.colla at fastwebnet.it> wrote:
>>>> Whatever it was, it's got fixed in the meantime.
>>> You installed it as root to a place where your normal user has no write access.
>> Then there's a bug, because the full scenario is:
>>
>> The lazarus tree installed from rpm is in /usr/lib (or /usr/lib64) where
>> normal user has no write access.
>> A custom executable is on ~/.lazarus_1.4 (--pcp= etc) where normal user
>> has write access.
>> A "Build Lazarus" should therefore build a new custom executable in
>> ~/.lazarus_1.4 where the normal user has write access, and actually it does.
>>
>> Given this scenario, the only place where a "clean all" needs to work is
>> on the writeable local tree: if sources are located on a non writeable
>> path is not relevant.
>> Without a "clean all", a number of stale ppu's where left in place in my
>> writeable path.
>> I could build only by removing by hand ppu's in my writeable path.
>>
>> The appropriate check should be if the *target* path is writeable. If
>> it's not, then it's impossible to build. If it is, then it's possible to
>> clean it in any way: automatically, clean common, clean all.
> The "Clean All" is calling "make clean". That only works in the
> Lazarus source directory.
> There is a "clean up" for the project and its packages, but not yet for
> the IDE and its packages.
> Missing feature.

After some further analysis, I'm becoming convinced that clean all would 
be unnecessary, 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.
 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.
The second solution would avoid unnecessary recompilations, e.g. when 
the custom version uses a different WS. 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.

If nobody detects a basic flaw in my considerations, I'd add an entry in 
the bugtracker, with target 1.6.

Now it's a bit late to start playing with TLazPackageGraph for 1.4, I 
believe.

Giuliano

-- 
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20150220/6fbb75bc/attachment-0003.html>