[bug] CMakeDeps: CONAN_CMAKE_SILENT_OUTPUT ignores FATAL_ERROR messages

[timpatt]

When using CMakeDeps we can set CONAN_CMAKE_SILENT_OUTPUT to silence the output from all calls to conan_message. As of Conan 1.45.0, this will also mean that those messages with side effects (ie. MESSAGE_TYPE of FATAL_ERROR or SEND_ERROR) will not execute either.

It should probably be something like:

function(conan_message MESSAGE_TYPE MESSAGE_CONTENT)
	if(NOT CONAN_CMAKE_SILENT_OUTPUT OR MESSAGE_TYPE STREQUAL "FATAL_ERROR" OR MESSAGE_TYPE STREQUAL "SEND_ERROR")
		message(${MESSAGE_TYPE} "${MESSAGE_CONTENT}")
	endif()
endfunction()

[memsharded]

This should be reconsidered with the whole Conan output strategy, not isolated, to be discussed in #11393

Most likely it shouldn't be a CONAN_ CMake variable to control that, but some other strategy to define the level of verbosity that is desired for tools too.

[memsharded]

Lets do:

• Remove conan_message() method completely
• Use standard CMake message() levels

[petamas]

I've just ran into this issue.

@memsharded : What does your decision in the above comment mean? How will this fix CONAN_CMAKE_SILENT_OUTPUT? Or does this mean that this whole variable/feature will be dropped, i.e. no more silencing?

I also think this is related, i.e. the "right way" would be to respect the QUIET argument of find_package instead of a conan-specific variable: #9959

[memsharded]

Yes, at the moment we are going to drop CONAN_CMAKE_SILENT_OUTPUT. Then use different CMake message() DEBUG, etc levels. It doesn't make sense to have a custom mechanism for this. The problem with the QUIET argument is that as it is hardcoded in the consumer CMakeLists.txt doesn't easily allow to debug things, and Conan finding the right package, unless the code in CMakeLists.txt is modified, which is not nice. We think the CMake verbosity levels should be the way to activate or deactivate the informational messages

[petamas]

@memsharded: conan_message() seems to be still present in conan 1.52.0 (https://github.com/conan-io/conan/blob/develop/conans/client/generators/cmake_common.py#L235), and it is still added and used in the cmake_find_package generator. What is the plan with this? If it is being kept in the long run, then this same issue is still present.

The problem with the QUIET argument is that as it is hardcoded in the consumer CMakeLists.txt doesn't easily allow to debug things, and Conan finding the right package, unless the code in CMakeLists.txt is modified, which is not nice.

In our (application) project, we want exactly this, i.e. we want to be able to control from our CMakeLists how "chatty" conan is. If/when I'm debugging conan issues, it is useful to have all these log lines, but not in the general usecase; we would be fine with removing the QUIET qualifier when debugging conan issues.

Alternatively, you could move the messages to a hidden by default log level (VERBOSE, DEBUG or TRACE). There are many useful log messages on STATUS, so we don't want to hide those, but the conan messages drown out everything at the moment. :-/
These are the two most annoying ones (the equivalents of which were moved to VERBOSE in #11625):

conan_message(STATUS "Library ${_LIBRARY_NAME} found ${CONAN_FOUND_LIBRARY}")
conan_message(STATUS "Found: ${CONAN_FOUND_LIBRARY}")

[memsharded]

@memsharded: conan_message() seems to be still present in conan 1.52.0 (https://github.com/conan-io/conan/blob/develop/conans/client/generators/cmake_common.py#L235), and it is still added and used in the cmake_find_package generator. What is the plan with this? If it is being kept in the long run, then this same issue is still present.

Hi @petamas

That is the cmake legacy generator, we didn't remove it from 1.X, because it would be breaking, but it has been superseded by CMakeDeps and CMakeToolchain in 1.X, and it will be fully removed in 2.0 (coming soon). Please have a look at those and let us know (they have removed the conan_message() function, relying only on pure CMake message() levels)