[fpc-devel] strange error "checksum changed" in package, when compiling project.

Martin 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 
code.

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 
increased.
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 mailing list