<meta content="text/html; charset=windows-1252"
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Il 19/02/2015 14:10, Mattias Gaertner
<pre wrap="">On Thu, 19 Feb 2015 13:44:03 +0100
Giuliano Colla <a class="moz-txt-link-rfc2396E" href="mailto:email@example.com"><firstname.lastname@example.org></a> wrote:
<pre wrap="">Il 19/02/2015 12:32, Juha Manninen ha scritto:
<pre wrap="">On Thu, Feb 19, 2015 at 1:10 PM, Giuliano Colla
<a class="moz-txt-link-rfc2396E" href="mailto:email@example.com"><firstname.lastname@example.org></a> wrote:
<pre wrap="">Whatever it was, it's got fixed in the meantime.
<pre wrap="">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
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.
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.<br>
In a situation where lazarus tree is not writeable, and a different
user path must be used, what happens currently is:<br>
<li>TLazPackageGraph.CheckIfCurPkgOutDirNeedsCompile checks from
lazarus tree if the compilation is required. </li>
<li>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.<br>
<li>If no compilation is required, compilation is skipped, and
anything leftover in the user path remains untouched. That's the
<li>When linking user path takes precedence over lazarus tree path
(newly compiled must take precedence over old ones), and invalid
leftovers abort the linking.</li>
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.<br>
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.<br>
If nobody detects a basic flaw in my considerations, I'd add an
entry in the bugtracker, with target 1.6. <br>
Now it's a bit late to start playing with TLazPackageGraph for 1.4,
<pre class="moz-signature" cols="72">--
Project planning question: when it's 90% done, are we halfway or not yet?