[BUG] No way to set RMM_LOGGING_LEVEL when building Python module

[harrism]

Describe the bug
When building the RMM Python module, passing -DRMM_LOGGING_LEVEL=TRACE or -DSPDLOG_ACTIVE_LEVEL=SPDLOG_ACTIVE_LEVEL_TRACE to the cmake configuration does not change the SPDLOG_ACTIVE_LEVEL that is active when RMM C++ code is compiled, and so it is always at SPDLOG_ACTIVE_LEVEL_INFO.

Steps/Code to reproduce bug
In the RMM dev container, run build-rmm-python -DRMM_LOGGING_LEVEL=TRACE -DSPDLOG_ACTIVE_LEVEL=SPDLOG_ACTIVE_LEVEL_TRACE.

This has no effect on logging.

Expected behavior
All RMM_LOG_TRACE message should be printed to a file rmm_log.txt in the current directory when this is run.

Environment details (please complete the following information):

• Environment location: Lab DGX
• Method of RMM install: RMM dev container

Additional context
Add any other context about the problem here.

[vyasr]

Copying my message from Slack:

I'm not sure that this is something CMake is designed to support. If I configure a project with target_compile_definitions(X PUBLIC Y), that's indicating that anything compiling against this project needs to have that defined, just as with setting target_include_directories or target_link_libraries. In the case of header-only libraries I could see an argument why you might expect it to be overridable since there's no compilation, but OTOH it's not a generally well-defined behavior for the case where you have compiled components and I wouldn't expect CMake to specialize for that.

You could always make this work by having the C++ library configured by the Python library, e.g. by setting -DFIND_RMM_CPP=OFF. That's not a general solution because you don't want to do that for compiled libraries like libcudf (otherwise you'd recompile libcudf when building cudf Python) but it would work for this specific case (rmm, which is header-only).

One alternative here would be for the C++ CMake in rmm to set one macro that is the "default" logging level but then support a second macro that would override it. Then consumers of the headers would be able to override the logger, but the C++ library would have a default level. Again, this only really makes sense because of the header-only nature of the library.

Looks like there's an open CMake issue where one of the devs comes to a similar conclusion: https://gitlab.kitware.com/cmake/cmake/-/issues/24099

[harrism]

I don't see why this isn't doable. The RMM C++ cmakelists only creates a property with defined values, and a default. It never sets any compile definitions based on it. I found that this is working for Cython, but realized that SPDLOG requires both a compile-time definition and a run-time call to set the level on the logger object. So I created a PR to expose this via the RMM Python API.

[vyasr]

We discussed this offline, Mark is correct. I had assumed in conversation that the C++ CMakeLists.txt was actually setting compile definitions, which is not the case.