Closed codecircuit closed 4 years ago
Well, it's just a single feature of the library that depends on strf. You can use most of it without strf. There's no exporting of a "nice-to-have"-type dependency, so IIANM, exporting the dependency would mean failure when building code using cuda-kat. Right?
You cannot clearly describe these "nice-to-have" dependencies in CMake as far as I know. If the dependency is exported with CMake, CMake reports already an error if strf
is not found, but you want to use cuda-kat
with find_package(cuda-kat REQUIRED)
.
But I agree with you. Probably it is the best not to state the dependency explicitly if it is only a small feature of the library.
... but do have a look at the printf'ing-ostream, it's a really cool feature for debugging!
It looks really nice! On top of that one can now build logging libraries for CUDA kernels.
One side effect is that the compile time explodes, which is critical if you compile hundreds of kernels in your code.
That's true, it's very taxing in terms of compilation time. But it doesn't multiply your translation unit compilation time, it adds to it. So you get (+ const)* num translation units. Still, it ain't pretty.
Also wanted to direct your attention this question.
The library seems to depend on
strf
. With this PR the dependency is exported to users of the library.