[Lazarus] Lazarus Release Candidate 1 of 1.4
giuliano.colla at fastwebnet.it
Fri Feb 20 00:34:45 CET 2015
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
> 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
Project planning question: when it's 90% done, are we halfway or not yet?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lazarus