From: "Ulrich Müller" <ulm@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/devmanual:master commit in: ebuild-writing/common-mistakes/
Date: Tue, 30 Mar 2021 18:15:51 +0000 (UTC) [thread overview]
Message-ID: <1617128096.d922c8c08a951c2a5f4c057cf6e1174d0a12f5a9.ulm@gentoo> (raw)
commit: d922c8c08a951c2a5f4c057cf6e1174d0a12f5a9
Author: Sam James <sam <AT> gentoo <DOT> org>
AuthorDate: Sun Mar 21 02:36:43 2021 +0000
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Tue Mar 30 18:14:56 2021 +0000
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=d922c8c0
ebuild-writing/common-mistakes: slight grammar fixes/phrasing changes
Signed-off-by: Sam James <sam <AT> gentoo.org>
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>
ebuild-writing/common-mistakes/text.xml | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/ebuild-writing/common-mistakes/text.xml b/ebuild-writing/common-mistakes/text.xml
index 9455688..05380bf 100644
--- a/ebuild-writing/common-mistakes/text.xml
+++ b/ebuild-writing/common-mistakes/text.xml
@@ -93,7 +93,7 @@ There are several ways to fix non-verbose build logs depending on the build syst
'--disable-silent-rules' to econf, or use EAPI 5 where that argument is
passed automatically. 'emake V=1' should also work.</li>
- <li>For custom Makefiles you often have to write a patch. Try to get
+ <li>For custom Makefiles, you often have to write a patch. Try to get
upstream to include an option like 'V=1' to enable full verbosity.</li>
<li>Note that when building Go manually outside of the eclass, you
@@ -127,8 +127,8 @@ without purpose, e.g.:
</p>
<ul>
<li>
- new warnings on version bumps of GCC/glibc which the developer was not aware
- of at the point of coding
+ new warnings on version bumps of GCC/glibc of which the developer was not
+ aware at the point of coding
</li>
<li>
some autoconf checks will fail badly
@@ -147,9 +147,9 @@ without purpose, e.g.:
</li>
</ul>
<p>
-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.
+By turning off "-Werror", we will still see the warnings, but there is no reason
+that they cause compile failure. Note that Portage already emits QA
+notices about GCC warnings that can cause runtime breakage.
</p>
<p><b>How to fix</b></p>
@@ -179,8 +179,8 @@ Always check that it's really gone in the build log.
The compiler (e.g. 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
+mostly safe to leave these untouched, because 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.
next reply other threads:[~2021-03-30 18:15 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 18:15 Ulrich Müller [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 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-30 14:21 Julian Ospald
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
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=1617128096.d922c8c08a951c2a5f4c057cf6e1174d0a12f5a9.ulm@gentoo \
--to=ulm@gentoo.org \
--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