Skip to content

.github/workflows/build*: pass "-v" to ninja#1379

Merged
cbnolok merged 3 commits intoSphereserver:devfrom
MaxKellermann:ninja_v
Feb 17, 2025
Merged

.github/workflows/build*: pass "-v" to ninja#1379
cbnolok merged 3 commits intoSphereserver:devfrom
MaxKellermann:ninja_v

Conversation

@MaxKellermann
Copy link
Copy Markdown
Contributor

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

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.
@MaxKellermann
Copy link
Copy Markdown
Contributor Author

With "sloppiness", all "Uncacheable" are gone.

@cbnolok
Copy link
Copy Markdown
Contributor

cbnolok commented Feb 15, 2025

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

@MaxKellermann
Copy link
Copy Markdown
Contributor Author

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?

@cbnolok
Copy link
Copy Markdown
Contributor

cbnolok commented Feb 17, 2025

As far as i know, if you manually define CMAKE__FLAGS, CMake won't add its default flags

@MaxKellermann
Copy link
Copy Markdown
Contributor Author

What default flags do you mean?

@MaxKellermann
Copy link
Copy Markdown
Contributor Author

The wording in https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html doesn't sound like this omits any other flags.

@cbnolok
Copy link
Copy Markdown
Contributor

cbnolok commented Feb 17, 2025

I mean that calling cmake with -DCMAKE_C_FLAGS="-fpch-preprocess" will make CMake discard the value it sets by default for CMAKE_C_FLAGS, same for CXX.
From your link: "For each language, if this variable is not defined, it is initialized and stored in the cache using values from environment variables in combination with CMake's builtin defaults for the toolchain.".
https://cmake.org/cmake/help/latest/envvar/CFLAGS.html#envvar:CFLAGS, the default value would be obtained also from the environment variable CFLAGS, so anything put inside there would be discarded.
That said, it was just an observation and i'm not sure it would eventually make some practical difference when compiling Sphere for x86 or Arm.

@MaxKellermann
Copy link
Copy Markdown
Contributor Author

Specifying -DCMAKE_C_FLAGS will omit any flags set in the CFLAGS environment variable, yes, because cmake treats both equal. Is that what you call "its default flags"?

What default flags would be omitted on GitHub actions?

@cbnolok
Copy link
Copy Markdown
Contributor

cbnolok commented Feb 17, 2025

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

@cbnolok cbnolok merged commit 08a1554 into Sphereserver:dev Feb 17, 2025
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.

2 participants