.github/workflows/build*: pass "-v" to ninja#1379
Conversation
The CI log should be verbose so we can see what commands are really
being used, and it's pointless to use the default "beautified" ninja
output. In this case, I'd like to know why my ccache changes were not
used ("Hits: 0 / Uncacheable: 210"), see commit b06a46e
ccache cannot cache projects using PCH properly unless we allow it to be "sloppy" about it. See ccache manual.
Another improvement for ccache with GCC+PCH, see ccache maual.
|
With "sloppiness", all "Uncacheable" are gone. |
|
I doubt that it will ever be relevant, but what about avoiding to override default CMAKE_C_FLAGS and CMAKE_CXX_FLAGS? Time ago i added some custom variables to inject the flags via cli, with the last commit i renamed them to CUSTOM_C_FLAGS, CUSTOM_CXX_FLAGS, CUSTOM_EXE_LINK_FLAGS |
|
I don't understand. Why would you want to discard the values of user-specified cmake flags variables and instead define new ones with different names? |
|
As far as i know, if you manually define CMAKE__FLAGS, CMake won't add its default flags |
|
What default flags do you mean? |
|
The wording in https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html doesn't sound like this omits any other flags. |
|
I mean that calling cmake with |
|
Specifying What default flags would be omitted on GitHub actions? |
|
As i said, probably nothing will be omitted because nothing might be stored in the C(XX)FLAGS env variable in this case, nor anything relevant might be set by default by CMake for a given compiler/build type. It's a personal over-concern about reproducibility and predictability in different contexts, when people might want to just copy/paste what we wrote in the action and compile on their machine |
The CI log should be verbose so we can see what commands are really being used, and it's pointless to use the default "beautified" ninja output. In this case, I'd like to know why my ccache changes were not used ("Hits: 0 / Uncacheable: 210"), see commit b06a46e