build: undo Werror=unused-variable #17533
Conversation
Partial revert of 18b18f8. First we need to avoid tripping this check whenever a dependency introduces an unused variable.
|
ACK f327e82 |
|
What is actually failing with |
|
@fanquake It depends on what libraries your system comes with. E.g. it fails when your system ships a "broken" boost: https://travis-ci.org/bitcoin/bitcoin/jobs/613924094#L10291 |
|
@MarcoFalke Right, but that failure isn't using system Boost, it's building Boost from depends. So are we assuming that builds for people using The problem this PR is "fixing", which is unclear from the description, is that 15382 introduces a dependency on Boost Process, and in Boost 1.70.0 (used in depends) there is an unused variable in the process module I just want to be clear why this is being reverted, because when it was introduced in #17486, depends and system libs seemed to be building fine under |
|
I'd presume that this also fails when a system library is broken, but I haven't checked. |
|
In my experience it only failed on a PR that started using a previously unused part of Boost #15382. We could of course leave this PR open until it actually breaks something on Travis. Maybe #14920 is merged before that's needed.
I can also produce that failure with system Boost in that PR, but only 1.70; it was fixed in 1.71 |
Gitian builds
|
|
Going to close this. If this change is required by a PR (#15382), it should be included in that PR (looks like it is), rather than applied to the build system in advance. Also see my comment above; #17533 (comment). #15382 could also be taking other approaches, like at least patching boost process in depends, rather than reverting a good, project-wide build system change because a single optional function causes issues. |
Partial revert of #17486.
First we need to avoid tripping this check whenever a dependency introduces an unused variable.
#14920 tackles this