<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Il 20/02/2015 00:23, Giuliano Colla ha
scritto:<br>
</div>
<blockquote cite="mid:54E6708D.80409@fastwebnet.it" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Il 19/02/2015 14:10, Mattias Gaertner
ha scritto:<br>
</div>
<blockquote
cite="mid:20150219141041.70ca3673@limapholos.matflo.wg"
type="cite">
<pre wrap="">On Thu, 19 Feb 2015 13:44:03 +0100
Giuliano Colla <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:giuliano.colla@fastwebnet.it"><giuliano.colla@fastwebnet.it></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Il 19/02/2015 12:32, Juha Manninen ha scritto:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Feb 19, 2015 at 1:10 PM, Giuliano Colla
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:giuliano.colla@fastwebnet.it"><giuliano.colla@fastwebnet.it></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Whatever it was, it's got fixed in the meantime.
</pre>
</blockquote>
<pre wrap="">You installed it as root to a place where your normal user has no write access.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<br>
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>
<br>
</blockquote>
please read "if clean auto didn't have a flaw"!!<br>
<blockquote cite="mid:54E6708D.80409@fastwebnet.it" type="cite"> In
a situation where lazarus tree is not writeable, and a different
user path must be used, what happens currently is:<br>
<ol>
<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>
<li>If no compilation is required, compilation is skipped, and
anything leftover in the user path remains untouched. That's
the flaw.<br>
</li>
<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>
</ol>
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>
<br>
If nobody detects a basic flaw in my considerations, I'd add an
entry in the bugtracker, with target 1.6. <br>
<br>
Now it's a bit late to start playing with TLazPackageGraph for
1.4, I believe.<br>
<br>
Giuliano<br>
<pre class="moz-signature" cols="72">--
Giuliano Colla
Project planning question: when it's 90% done, are we halfway or not yet?
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
_______________________________________________
Lazarus mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Lazarus@lists.lazarus.freepascal.org">Lazarus@lists.lazarus.freepascal.org</a>
<a class="moz-txt-link-freetext" href="http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus">http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Giuliano Colla
Project planning question: when it's 90% done, are we halfway or not yet?
</pre>
</body>
</html>