TBB is not used, but we decided that TBB is the way to use threading for all dune modules. Thus we provide the test by dune-common for all module.
So dune-common should depend on GMP and TBB. dune-istl doesn't depend on them and cmake shouldn't mention them.
You seem to propagate dependencies and make many or all dependencies of dune-common dependencies of their dependent project, which isn't a common practice. For example, Qt might depend on ffmpeg for one of its functions, but this doesn't induce ffmpeg as dependency on all Qt users.
@yuri.vic thanks for reporting your impression on the "broken" cmake system. While, I think, the dune system cannot directly be compared to the Qt system, there is actually something true in your issue. We are investigating already a cleanup of the whole cmake system, but this is not a simple issue and will take a lot of time, since, e.g., it must happen in a backwards compatible way and the dune cmake system is quite complex.
Regarding your concrete points: if a package is not a pure build-only (private) dependency, but a usage dependency (public) it must be propagated and tested-for again. The dune system currently works that all usage-dependencies are propagated to all downstream modules, i.e., a cmake file from all upstream-modules is processed again. Thus, e.g., GMP and TBB are configured again in dune-istl even if it is introduced in dune-common. This is not dune-specific but the way cmake works. All imported targets associated to an upstream library must be defined (thus searched-for and configured) on any downstream module. The "feature-summary" at the end of the cmake configuration is a cmake function that just reports which packages were processed in which way.
If, e.g., dune-common finds TBB, it sets the compile-flags HAVE_TBB=1 and depending on this flag it might compile code in dune-common, and also enables sections of the header files. Now, in dune-istl we have to require that TBB is also found and thus also the HAVE_TBB is set, otherwise we would get diverging header files, that might end up in horrible compiler/linker errors. So, the package-configuration must be compatible. While the HAVE_TBB flag could be propagated directly, if we have to link a library it must exist in the system and thus be found, even if we compile dune-common and dune-istl independently.
Once dune-common is installed - this guarantees that TBB is installed. In dune-istl you can inernally check that HAVE_TBB is set, but the user doesn't need to see that TBB is a dependency, because you don't immediately use it in dune-istl. Rather, it is a hierarchical dependency, implicitly guaranteed to be present.
while this might be true, the current way of guaranteeing that it is present, i.e. a find_package() call succeeds, automatically sets this information in the feature-summary. So, we would somehow have to deactivate the standard cmake behaviour for possibly all packages in any upstream module that was found before. While there are ideas to replace this current system with something else, this is not yet decided on and not yet worked through.
Also, while it is not used directly in dune-istl, it might be of actual interest to a user of dune-istl that she can use these features, e.g., to implement a linear operator or vector that uses shared-memory parallelization (using TBB) on its operations, e.g. dot products, element-wise operations or matrix-vector products.