Paul Fultz II

Some notes from Daniel's slides: ``` [B, dBlock, kIter, kpackPerBlock, dPerBlock, kpack] B = Batch K = kIter*kpackPerBlock*kpack D = dBlock*dPerBlock kIter = K/(kpackPerBlock*kpack) [B, dBlock, kIter, kpackPerBlock, dPerBlock, kpack]...

> I also considered moving the FileLister but have not looked into it yet. Should probably go into frontend instead. I can do that, but then dmake would depend on...

> And this could be extended for variadic parameters by using recursion: Actually this is not needed. `auto_preload` will do this for multiple parameters, and its setup as an arg...

These issues can be addressed without reverting the PR. I do have #8016 to address the `BUILD_CORE_DLL` issue, and I am working on some other updates to try to address...

> the introduced dependencies reduce the parallelisms in the project since the target have to be complete before other files can be build (most visible with using ninja) Let me...

> So it has nothing to do with how CMake is structured It does, since its a one line fix instead of multi-line multi-file change.

> It does not. Before it was just building everything until it arrived at the first linking (static libraries are being linked - and with GCC it is slow). Now...

This is the error I see: ``` /Users/paul/github/danmar/cppcheck/lib/cppcheck.cpp:877:16: error: no matching constructor for initialization of 'simplecpp::TokenList' return simplecpp::TokenList{data, size, files, file.spath(), outputList}; ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/paul/github/danmar/cppcheck/externals/simplecpp/./simplecpp.h:230:9: note: candidate constructor not viable:...

Can we merge this in? As I cannot build cppcheck locally on my mac.

> This has been "superseded" by https://github.com/danmar/cppcheck/pull/7962. Thats not even merged in and its a draft PR. This should be merged first since it fixes the build issues as cppcheck...