Il 20/02/2015 01:32, Mattias Gaertner ha scritto:
On Fri, 20 Feb 2015 00:23:57 +0100
Giuliano Colla <[email protected]> wrote:
[...]
After some further analysis, I'm becoming convinced that clean all would
be unnecessary,
There are always cases when a clean all is needed.
For example when an unit is moved to another package. The compiler
options are exactly the same, but you have to delete the old
ppu files.
Let's say, would be less necessary.
it clean auto didn't have a flaw in how package
compilation is handled in TLazPackageGraph.
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.
What exactly is flawed?
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.
Do you mean line 3237?
I rather mean line 3206.
If normal output directory (i.e. the not writeable one, in our case)
doesn't need compile, no check is made on the fall back directory.
If the fall back directory is empty (as it would be on a first time
build) , a useless compilation is avoided, and this is Ok, but if it
contains old ppu's (as it may happen after an update) the old ppu's are
left in place, and will cause linking to abort.
I'll make some tests on the transition from 1.2.6 to 1.4RC1 which shows
the problem, to see if some smarter checks on PackageSytem can help, or
if, after all, a clean all is the only viable solution.
Are there cases where a package units directory contains units from more
than one package?
Giuliano
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
