Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DRAFT: FOR COMMENTS Support verbosity in cmake output #408

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

coldav
Copy link
Collaborator

@coldav coldav commented Mar 19, 2024

Overview

For message cmake commands replace with ca_message and support a verbosity level which can be changed using CA_CMAKE_VERBOSE_LEVEL(0 none, 1 summary, 2 detail). Including from LLVM will by default set to 0.

Reason for change

Including from LLVM was noisy

For message cmake commands replace with ca_message and support a verbosity
level which can be changed using CA_CMAKE_VERBOSE_LEVEL(0 none, 1 summary,
2 detail). Including from LLVM will by default set to 0.
# Even if in LLVM tree we support overriding of the verbosity level
if (NOT CA_CMAKE_VERBOSE_LEVEL STREQUAL "")
set(OCK_CMAKE_VERBOSE_LEVEL ${CA_CMAKE_VERBOSE_LEVEL})
endif()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be a cached variable so that if CMake decides it needs to re-run itself, the previously set verbosity level gets picked up. It also means we only need a single variable because cache variables by default (if FORCE is not used) do not override user settings.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did initially go that way, but it seemed to require the fetcher to set the variable, rather than doing it by default in "inside llvm".

set(OCK_IN_LLVM_TREE TRUE)
# We always reduce verbosity level if included in LLVM tree
set(OCK_CMAKE_VERBOSE_LEVEL "0")
endif()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could just keep the default as always verbose, and override it from within DPC++.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did think about that, I was worried that we end up adding loads and loads of cmake options before including it and maybe this was another way.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If DPC++ native CPU wants loads of things different from what we want as the default, there's probably a bigger problem that we should discuss. I would expect that a list of just those things where DPC++ wants something different to be relatively short, shorter than repeated OCK_IN_LLVM_TREE checks. Is that not the case?

@@ -71,11 +72,11 @@ macro(ca_option name type description default)
# Setup the main option of this macro.
if(${type} STREQUAL "BOOL")
option(${name} ${description} ${default})
message(STATUS "oneAPI Construction Kit ${description}: ${${name}}")
ca_message(STATUS CA_VERBOSE_DETAIL "oneAPI Construction Kit ${description}: ${${name}}")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

STATUS already indicates the verbosity, and CMake has ways of automatically suppressing noise based on the requested verbosity level (CMAKE_MESSAGE_LOG_LEVEL). We could use that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that, but it felt that we should output all warnings by default, and STATUS could have two levels i.e. summary information and detail information. The only one I felt has real meaning for me is the LLVM version when i run it. However I am open-minded we could just use STATUS etc as you suggest.

Copy link
Collaborator

@hvdijk hvdijk Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ones that you mark as verbose here do have meaning for me, I check them almost every time I need to re-run CMake to make sure I didn't leave some extension off that I will be trying to test. But I wouldn't mind marking them as message(VERBOSE [...]) provided we continue to see them in our own CI, if it makes it easier for you to suppress what is just noise to you.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CMAKE_MESSAGE_LOG_LEVEL would be across LLVM too, whereas I think they want to only suppress OCK messages

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CMake variables have directory scope. If set in a subdirectory, it should only affect that subdirectory without affecting the rest of LLVM.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did try that, but I'll try again.

endif()
list(REMOVE_AT ARGV 0)
list(REMOVE_AT ARGV 0)
if (${CA_MESSAGE_VERBOSITY_LEVEL} LESS_EQUAL ${OCK_CMAKE_VERBOSE_LEVEL})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CMake's if command is weird and in most cases, variables should not be expanded explicitly, because if will already try to expand them and you run the risk of double expansion. if(CA_MESSAGE_VERBOSITY_LEVEL LESS_EQUAL OCK_CMAKE_VERBOSE_LEVEL) should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants