[gentoo-commits] proj/devmanual:master commit in: ebuild-writing/common-mistakes/

public inbox for gentoo-commits@lists.gentoo.org
 help / color / mirror / Atom feed

From: "Julian Ospald" <julian.ospald@googlemail.com>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/devmanual:master commit in: ebuild-writing/common-mistakes/
Date: Sun, 30 Dec 2012 14:21:14 +0000 (UTC)	[thread overview]
Message-ID: <1356877263.dab546b74d223852bf2d6bec3ad9918d353c9859.hasufell@gentoo> (raw)

commit:     dab546b74d223852bf2d6bec3ad9918d353c9859
Author:     hasufell <julian.ospald <AT> googlemail <DOT> com>
AuthorDate: Sun Dec 30 14:21:03 2012 +0000
Commit:     Julian Ospald <julian.ospald <AT> googlemail <DOT> com>
CommitDate: Sun Dec 30 14:21:03 2012 +0000
URL:        http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit;h=dab546b7

document handling of -Werror wrt #415979

---
 ebuild-writing/common-mistakes/text.xml |   50 +++++++++++++++++++++++++++++++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/ebuild-writing/common-mistakes/text.xml b/ebuild-writing/common-mistakes/text.xml
index b486a7e..549cb00 100644
--- a/ebuild-writing/common-mistakes/text.xml
+++ b/ebuild-writing/common-mistakes/text.xml
@@ -94,6 +94,56 @@ preferred.</note>
 </subsection>
 
 <subsection>
+<title>-Werror compiler flag not removed</title>
+<body>
+"-Werror" is a flag which turns all warnings into errors and thus will abort compiling if any warning is encountered.
+
+<p><b>Rationale</b><p />
+This flag is not recommended for releases and should always be disabled when encountered in build-logs, because there are numerous cases where this breaks without purpose, e.g.:
+<ul>
+  <li>
+    new warnings on version bumps of GCC/GLIBC the developer was not aware of at the point of coding
+  </li>
+  <li>
+    some autoconf checks will fail badly
+  </li>
+  <li>
+    libraries adding deprecated API warnings although that API is still working/supported
+  </li>
+  <li>
+    on less known architectures we may get different/more warnings than on common ones
+  </li>
+  <li>
+    random breakage depending on what distro/architecture/library version/kernel/userland the developer was testing "-Werror" on
+  </li>
+</ul>
+Turning off "-Werror" we will still see the warnings, but there is no reason that they cause compile failure. Also note that portage already emits QA notices about gcc warnings that can cause runtime breakage.
+</p>
+
+<p><b>How to fix</b><p />
+To fix the affected build system you should try the following methods:
+<ul>
+  <li>
+    remove the compiler flag from the build system, <e>e.g. Makefile.am or configure.ac</e> or even provide a switch (for autotools based build systems that could be "--disable-werror", which is good for sending a patch upstream)
+  </li>
+  <li>
+    use <e>append-flags -Wno-error</e> (needs flag-o-matic.eclass); for this to work the environment flags have to be respected and placed after build system flags; this method is not preferred as it will disable all "-Werror=specific-warning" flags as well, see next section
+  </li>
+</ul>
+Always check that it's really gone in the build log.
+</p>
+
+<p><b>Specific -Werror=... flags</b><p />
+GCC can turn any specific warning into an error. A specific -Werror flag would be "-Werror=implicit-function-declaration" for example and will only affect warnings about implicit function declarations. It's mostly safe to leave these untouched, cause they are pinned to this issue and should not cause random build time breakage. Also, we can expect that upstream did this on purpose to avoid known runtime errors and not just for testing their builds. However you should check the specified warnings yourself or ask other developers if unsure.
+</p>
+
+<p><b>Exceptions</b><p />
+Removing "-Werror" from configure.ac can cause breakage in very rare cases where the configure phase relies on the exit code. See <uri link="http://sourceforge.net/tracker/?func=detail&amp;aid=2959749&amp;group_id=204462&amp;atid=989708">app-emulation/open-vm-tools bug</uri>. But even then we remove it from the resulting Makefile.
+</p>
+</body>
+</subsection>
+
+<subsection>
 <title>Missing/Invalid/Broken Header</title>
 <body>

next             reply	other threads:[~2012-12-30 14:21 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-30 14:21 Julian Ospald [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-07-24 14:15 [gentoo-commits] proj/devmanual:master commit in: ebuild-writing/common-mistakes/ Ulrich Müller
2022-01-22 23:43 Sam James
2021-12-22 15:38 Ulrich Müller
2021-09-17  9:09 Ulrich Müller
2021-08-14 10:00 Ulrich Müller
2021-08-01  2:43 Sam James
2021-08-01  2:38 Sam James
2021-08-01  2:38 Sam James
2021-08-01  2:38 Sam James
2021-08-01  2:38 Sam James
2021-08-01  2:38 Sam James
2021-03-30 18:20 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 18:15 Ulrich Müller
2021-03-30 16:10 Ulrich Müller
2021-03-30 16:10 Ulrich Müller
2021-03-29 20:44 Ulrich Müller
2021-03-21  6:06 Ulrich Müller
2021-02-06 10:35 Ulrich Müller
2017-01-25  5:31 Göktürk Yüksek
2017-01-25  5:31 Göktürk Yüksek
2017-01-21 19:21 Göktürk Yüksek
2016-10-28 17:13 Ulrich Müller
2016-02-05 12:59 Ulrich Müller
2014-10-18 17:36 Markos Chandras
2014-05-13 19:32 Ulrich Müller
2013-09-28 12:19 Markos Chandras
2012-12-04 19:26 Julian Ospald
2012-11-23 18:02 Julian Ospald
2012-11-17 19:00 Markos Chandras
2012-11-11 19:33 Markos Chandras
2012-11-07 13:27 Michael Palimaka
2012-11-07 13:25 Michael Palimaka
2012-08-08 19:20 Markos Chandras
2011-03-09 16:42 Jeremy Olexa

find likely ancestor, descendant, or conflicting patches for this message:
( dfblob:b486a7e dfblob:549cb00 )
 OR (
bs:"[gentoo-commits] proj/devmanual:master commit in: ebuild-writing/common-mistakes/" )
	(help)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1356877263.dab546b74d223852bf2d6bec3ad9918d353c9859.hasufell@gentoo \
    --to=julian.ospald@googlemail.com \
    --cc=gentoo-commits@lists.gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Be sure your reply has a Subject: header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox