[Lazarus] Lazarus Release Candidate 1 of 1.4

[Giuliano Colla]

Il 20/02/2015 00:23, Giuliano Colla ha scritto:
> 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.
>
please read "if clean auto didn't have a flaw"!!
> 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?
>
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


-- 
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/c30397b0/attachment-0003.html>