use checksum for filecache name instead of lookup file

[rsBNT]

The old situation was that all found/accepted filenames were written to a lookup files.txt which mapped between absolute filename, configuration (if available from e.g. vcxproj) and the cached buildresult filename.
This file was always generated upfront (before analysis/tokenizing) and if filenames occured multiple times, a counter was incremented (e.g. main.a0, main.a1, etc.).

So if a solution was scanned via --project that contained a subset of projects/files of a previously scanned solution, the order of the found/accepted filenames might have been different. In this situation, the hashes did not match the files anymore, and files were rescanned. The same could have been triggered by filesystem sorting changes, file renaming, etc.

The suggested changes make the lookup unnecessary (many file operations to files.txt are gone) by taking the checksum as filename. This should be unique enough and is computed at this point anyways.

This way, the order of filenames (and actually the filenames themselves) is not important anymore but only the file contents which is the true intention after this feature (used for differential/incremental scans).

There is one problem though: build-dir clutter. When relying on the file contents instead of filenames, it is hard to track which temporary build file is stale/outdated. Because when file contents change, the old hashfile will reside in the build dir. I suggest this is ok if mentioned and users should clean the build dir regularly (e.g. when forcing a complete rescan) or on filetime base (hashfile hasnt changed in ages). After all, the same origin fileversion might be rechecked at some point and then the scan is greatly accelerated (think git bisect and you check each version with cppcheck).

[rsBNT]

Sorry for the hickups, downloading Qt now to test it properly locally :/

[rsBNT]

I reverted the changes to the GUI and put back in the parts of the AnalzerInfo API that were required for it. Seems like that API is used for various different things (check cache, plugins, ...).

[rsBNT]

Can anybody point me to the problem that Travic CI is having? I dont see what its complaining about :/

[matthiaskrgr]

Hi, the makefile is out of date.
run make dmake ; ./dmake" and commit the result.

[rsBNT]

Thanks for the hint, how would i do this on windows?

[rsBNT]

@matthiaskrgr now what? can you help me identify the problem in the logfile? i dont see the error :/

[amai2012]

Isn't it a compile error at https://travis-ci.org/danmar/cppcheck/jobs/306245643 (see end of log)?

[rsBNT]

@amai2012 yeah, that i fixed with this commit. In the most current runner i cant see the error :( It builds locally just fine (Windows VS2015, Release|x64) and GUI (Qt5.9.3 MinGW Release 32bit and MSVC2015 Release|x64).

[amai2012]

Seems I've been looking at the wrong Job.
https://travis-ci.org/danmar/cppcheck/jobs/306856532 seems to end with a big diff in the Makefile...

[rsBNT]

@amai2012 and is that ok or is that the problem? I regenerated the Makefile using the instructions above on a linux machine (because i wouldnt know how to do that on Windows).

[matthiaskrgr]

Hi, it might just be an an incompatibility with different line endings or something like that. If the pr is merged, someone else can simply rerun dmake and push that. And build will "succeed" again.

I think I might be able to add a dmake-only job to travis and set it to "is allowed to fail".

[rsBNT]

@matthiaskrgr that would be great, thanks! In the meantime, is there anything i can do to make this PR presentable again? :) I would really appreciate it if this PR was considered for the next release.

[matthiaskrgr]

If you rebase now it might work :)

[rsBNT]

If master was building properly ;) Thanks for your support!

[danmar]

well you can use different build dirs for different analysis. but I am not against that the build dir can be reused, this is an enhancement.

[danmar]

I am not sure about this.

I think that stale files is a problem. Every time a file is changed, a buildfile will become stale.

I do like that it's possible to see what source file a "buildfile" refers to.

Can we please try some other solution? For instance; I don't think that it's necessary to rewrite files.txt, additional files can be appended if needed..

[danmar]

Also.. I am very sorry that it took so long for review. Feel free to ping every couple of days if you want a quicker review.

[rsBNT]

No worries, its a major change and i see you are busy with lots of other changes, so it just takes its time. I will think about changing it somehow.

[amai2012]

If the files being analyzed had unique names (e.g. absolute path) one might combine file mapping and stable file names by using filename.<_hash_created_from_fullpath_>?!

[danmar]

Can we please try some other solution? For instance; I don't think that it's necessary to rewrite files.txt, additional files can be appended if needed..

I close this. Feel free to open a new PR if you have a new solution.