[fpc-devel] strange error "checksum changed" in package, when compiling project.
lazarus at mfriebe.de
Sun Oct 20 22:54:18 CEST 2013
On 20/10/2013 20:40, Jonas Maebe wrote:
> On 20 Oct 2013, at 19:33, Martin wrote:
>> I see there are still open related issues, so maybe some hope...
>>> That is how the inlining is implemented by design currently. The availability of an inline function body changes the unit interface checksum, so that other units using that unit will be recompiled the next time and can use the inline body (since the first time the inline body was not yet available, it could not yet be inlined).
>> I have a very limited understanding of this, but I think I disagree (well I do disagree, I think tha I am correct to do so...)
>> AFAIX, ppu already have more than one checksum?
>> Then it would just be a question to make that yet another checksum. And if *only* this new checksum has changed, then recompile *if* the source is available.
>> If not, than keep things as they are.
> Changing the behaviour of the compiler depending on whether or not the source code is available is not acceptable. The only reasonable alternative in my eyes would be to never inline anything in case of mutually dependent units (like Delphi does). Additionally, afaik compiling with -Ur already works around the problem today.
Together with a note or hint, that would also be acceptable.
Not havng an optimization, is still better than failing to compile valid
There also is http://bugs.freepascal.org/view.php?id=7370
(If I understand correct) About recompiling immediately, until all
changes are resolved.
I can see from the comment (and I do agree) that this is not a
favourite. But IMHO the following could be acceptable:
- do not recompile by default. (for optimization changes / this will
leave those units without the optimization for good)
- Have a command line argument that tells the compiler how often to
recompile, if needed. (may require a recompile count field in the ppu)
- only recompile, if the change was due to optimizations (possible if
those changes are having their own checksum)
The optimization checksum also would be needed to make the count field
work. If only the optimization checksum changed, then the count is
If something else changed, it will follow current behaviour (and if that
writes a new ppu, then it resets the count.
More information about the fpc-devel