<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 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 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 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>
    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>
  </body>
</html>