remove conan_message #11625
remove conan_message #11625
Conversation
| @@ -66,13 +66,13 @@ def template(self): | |||
| foreach(_COMPONENT {{ '${' + pkg_name + '_COMPONENT_NAMES' + '}' }} ) | |||
| if(NOT TARGET ${_COMPONENT}) | |||
| add_library(${_COMPONENT} INTERFACE IMPORTED) | |||
| conan_message(STATUS "Conan: Component target declared '${_COMPONENT}'") | |||
| message(STATUS "Conan: Component target declared '${_COMPONENT}'") | |||
There was a problem hiding this comment.
Would you be opposed to changing this and line 75 to VERBOSE instead of STATUS?
I have a project where several submodules import conan packages (the super project is only setting up CMake paths to all the conan packages, not importing them) and these messages get printed several times now. I was previously silencing them by setting CONAN_CMAKE_SILENT_OUTPUT.
There was a problem hiding this comment.
The thing is that this information is generally super helpful for many users, that will get the targets listed by default. Because not listing them makes challenging to know what would be the available target names, and changing the default verbosity of CMake for this is not that straightforward (or users won't really run in verbose, because they don't know that Conan will show the targets if they do that). So I am concerned about the experience for many Conan users, specially learners.
There was a problem hiding this comment.
I was worried you might say that :)
How about checking <PackageName>_FIND_QUIETLY within the generated code and if it's set either disable the message completely or change it to VERBOSE? That would give users control over the printing through the find_package call. I've never tried using this variable before, so unsure if it will actually work, but I could give it a shot and upload a PR.
I found related bug/feature requests too while Googling this, #10857 and #9959
There was a problem hiding this comment.
Yes, the current implementation do not implement QUIET handling, and it would make sense that it is listened. If you want to try it, these would be the guidelines:
- CMakeDeps only. It is not worth the effort of modifying the other legacy ones, Conan 2.0 is next month
- Don't overengineer with too much abstraction. A bit of repetition is not that bad if makes things cleaner.
Changelog: Fix: Remove
conan_message()inCMakeDeps.Docs: Omit
Close #11369