Skip to content

Conversation

@vasild
Copy link
Contributor

@vasild vasild commented Feb 14, 2020

Before this patch ./configure --enable-werror would selectively
turn only some warnings into errors, not all, by using
-Werror=foo -Werror=bar instead of a plain -Werror which turns all
warnings into errors.

To accommodate the new stricter build config, introduce
--enable-isystem to optionally suppress warnings from external headers
(e.g. boost, qt). That may be useful on systems that have them installed
outside of /usr/include. On Linux the external headers are typically
installed in /usr/include and so warnings from them are always suppressed.

@DrahtBot
Copy link
Contributor

DrahtBot commented Feb 14, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@hebasto
Copy link
Member

hebasto commented Feb 15, 2020

Suppress any warnings from Boost headers by marking them as system
headers.

Suppressing any warnings from Boost does not look great. Some related discussions about warnings from leveldb could be find in #16710 and #16722.

@vasild
Copy link
Contributor Author

vasild commented Feb 17, 2020

@hebasto

  • Warnings from external headers (boost, qt, etc) are already suppressed if they are installed in /usr/include. I guess this is the common case with Linux. So, we just add an option to achieve the same if external headers are installed in another location.
  • The new option is off by default.
  • It would allow us to reliably build our code with full -Werror (not a partial set of -Werror=...).

configure.ac Outdated
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not isystem? It would more closely match the behavior of the -I it replaces.
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because -idirafter /usr/include does not break gcc's #include_next, so I do not have to explicitly handle /usr/include in a different way.

Anyway, the --enable-isystem introduced in 572db3c in #14920 is superior to the above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just rebased on top of 572db3c and ditched the above piece.

Copy link
Contributor

@Empact Empact Feb 28, 2020

Choose a reason for hiding this comment

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

Here's a much pared-down version of 572db3c that looks to be effective (applied to Boost only):
master...Empact:2020-02-werror

Copy link
Contributor Author

Choose a reason for hiding this comment

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

master...Empact:2020-02-werror looks good. I confirm it works as expected on FreeBSD 12 with clang 9 - it makes it possible to compile Bitcoin Core with full -Werror! \o/

Are you going to create PR from it? If yes, then I will ditch this PR.

nit: the new option's description enable isystem includes for dependencies and stricter warning checks (default is no) warrants s/ and stricter warning checks//

Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

Feel free to cherry-pick and modify the subject. Deferring to you as the original author unless you want to punt.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. I also picked up the QT changes to get this working also with Clang 10.

@vasild vasild changed the title build: change --enable-werror to enable -Werror build: add --enable-isystem and change --enable-werror to enable -Werror Mar 3, 2020
@vasild vasild marked this pull request as ready for review March 4, 2020 10:39
@vasild
Copy link
Contributor Author

vasild commented Mar 4, 2020

@hebasto this PR went through some significant changes, I edited my comments accordingly and changed its status from "Draft" to "Open". Your re-review would be welcome.

Empact and others added 2 commits March 6, 2020 09:38
When configured with --enable-isystem.

Was necessary to split QT_INCLUDES into QT_INCLUDES and
QT_MOC_INCLUDES because moc does not understand -isystem, e.g.:

    Unknown options: isystem/usr/local/Cellar/qt/5.10.0_1/include/QtNetwork[...]

This patch treats just Boost and QT headers. The other external headers could be
added as well, should it be necessary.

Note -isystem should not be applied to /usr/include, see BITCOIN_SYSTEM_INCLUDE
for a helper to convert -I to -isystem with /usr/include excepted.
Before this patch `./configure --enable-werror` would selectively
turn only some warnings into errors, not all, by using
`-Werror=foo -Werror=bar` instead of a plain `-Werror` which turns all
warnings into errors.

To accommodate the new stricter build config, use --enable-isystem to
suppress warnings from external headers (e.g. boost, qt) on systems
that have them installed outside of /usr/include. On Linux the external
headers are typically installed in /usr/include and so warnings from
them are suppressed by default.
@vasild
Copy link
Contributor Author

vasild commented Apr 23, 2020

Closing this as it contains two not directly related changes - optional suppression of warnings from external headers and -Werror expansion. I will submit them separately.

@vasild vasild closed this Apr 23, 2020
@vasild vasild deleted the werror branch April 23, 2020 20:14
@vasild
Copy link
Contributor Author

vasild commented Apr 23, 2020

Took the idea of the first commit and re-implemented it in a (hopefully) better/shorter way in #18750

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants