Replies: 1 comment
-
I would recommend that you actually should be using the meson core option --werror, since it can be passed as a pipeline option in accordance with that blog post. Also, That means you can have your CI pipelines enforce Werror for code originating in the parent project relatively easily, while leaving all subprojects to compile cleanly (and maybe not even report warnings). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
we have a project that has a 0-warning-policy in the official pipelines. So, in gitlab we define --werror on the command line for our project. (Not generally with the core option werror though, as https://embeddedartistry.com/blog/2017/05/22/werror-is-not-your-friend/ makes a lot of sense.)
But this 0-warning-policy is, of course, only sensible for our own code, not for external subprojects. So, along comes another subproject that has some
[[deprecated]]attributes on symbols while still using those symbols. Therefore, while building this subproject, we get a ton of specific warning that come out as errors and break our pipeline.What is the official or recommended way of handling these situations? Of course, this is not specific to
[[deprecated]]! How can I make subprojects compile without warnings coming up as errors, while keeping the policy for our own project?Thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions