The main thing we want to do is avoiding doing something in a way that CMake maintainers would not recommend. It’s happened before and digging Android out of that hole is something that’s taken several years and still isn’t finished.
If “CMake shouldn’t have any part in this” is the answer, that’s totally fine with us, we just wanted to be sure that wouldn’t be a mistake
CC @brad.king, who’s been on the receiving end of our earlier mistakes and so probably has an opinion here.
I wouldn’t have expected sanitizers to cross into the installation space (it would normally be something purely driven by the consuming project).
Maybe they don’t. “Packaging” might have been a better word than “install”. For Android, the sanitizer runtimes may need to be packaged in the APK (it varies by sanitizer). One way we could handle that is for CMake to define install rules for the runtimes. Another is for the packager itself to infer that a sanitizer is being used and do that. The latter approach is how other parts of the build (like the C++ stdlib, as well as the build outputs themselves) are currently handled, and that doesn’t work very well IMO.
But you’re probably right and YAGNI.
Maybe I’m missing something about the problem you’re trying to solve.
This is probably more information than you want, but providing it just in case:
Android builds are typically a CMake build that’s invoked by a gradle plugin. The build.gradle file is where build variants need to be defined. Gradle needs to configure CMake appropriately, and either CMake needs to inform the gradle plugin which runtimes need to be installed (via https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html), or the plugin needs to be responsible for that itself.
My users find the behavior of
CMAKE_CXX_FLAGS surprising (the former cannot override the latter because they’re prepended rather than appended; the latter completely overrides the default flags for the platform; the behavior they want is to append to the defaults), so we prefer to implement this kind of thing indirectly, such as by having gradle pass
-DANDROID_SANITIZE=address,undefined, which our toolchain file (which is that unrecommended approach we’ve been trying to fix I mentioned above) would then interpret and configure appropriately.
Like I said above, we’re okay with that approach, but wanted to be sure it was actually recommended before we ship it.