Handling of "-Werror" set by build systems is undocumented. The common opinion on this seems to be "always remove/disable" (referring to dev ml) There is also this bug: https://bugs.gentoo.org/show_bug.cgi?id=260867 Actually I am not sure where this should go. Somewhere in http://www.gentoo.org/proj/en/qa/ or http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 As I am not an expert on this issue someone else should take over to write an appropirate section/article about this, plz.
I think it should go to http://devmanual.gentoo.org
What exactly do you want this section to include? We always remove "-Werror" from build systems. Do we really need to document that? QA, Diego, opinions?
lets assume the following rule: always filter -Werror then those quetions/notes remain a) are there exceptions to this rule? If so, when? b) should arch testers/ebuild writers be extra careful when -Werror has been filtered by an ebuild? (Werror might indicate that upstream faced severe runtime issues during development and introduced this flag) c) there are also specific -Werror flags such as -Werror=implicit-function-declaration and so on. Does this rule count for them as well? Are there specific Werror flags that can be left as they are? d) why and when does Werror actually break things without a good reason? Examples and cases...
a) exceptions? There are build systems that rely on the exit code and -Werror, like open-vm-tools, but even then the .ebuild is making sure the -Werror doesn't end up in the final build. Copy'n'paste from open-vm-tools for example: # Do not filter out Werror # Upstream Bug http://sourceforge.net/tracker/?func=detail&aid=2959749&group_id=204462&atid=989708 # sed -i -e 's/CFLAGS=.*Werror/#&/g' configure || die But this is the only exception I've ever seen, and doesn't really even qualify as an exception... b) filter? append...? Filtering is unreliable and append-flags -Wno-error should be preferred. This also means upstream build systems should append (or replace) build system's own CFLAGS with environment CFLAGS. Should never prepend (same rule of course applies to any flags, this is no way -Werror specific) c) should this be documented? Nah, common sense says we don't want packages randomly failing based on host, toolchain, etc. d) -Werror=something allowed? Not really. Some packages do this however, like X.org packages, bug 416069. Developers might use implicit-function-declaration to catch missing #include's (and matching -D flags) but then they should provide patches too, and report to upstream.
(In reply to comment #4) > b) filter? append...? > > Filtering is unreliable and append-flags -Wno-error should be preferred. > This also means upstream build systems should append (or replace) build > system's own CFLAGS with environment CFLAGS. > Should never prepend (same rule of course applies to any flags, this is no > way -Werror specific) hmm, wouldn't that actually disrespect users flags? He might want to add -Werror on purpose and append-flags will overwrite it.
-Werror is _not_ a valid user-defined cflags; the same goes for _any_ of the -Werror= flags. Among others, there are default autoconf checks that _will_ fail badly if used with -Werror (or some of the -Werror= values, of course). This means that it's not acceptable for an user to pass that on. Also, please note that -Wno-error might not always work as intended, as in some cases upstream is right with using some -Werror= flags, as they could cause runtime failures (stuff like implicit declarations and so on), and those should be respected. The difference between using -Werror and using -Werror={something,other,another} is that in the former case upstream might not be aware of new warnings introduced by new versions of GCC, GLIBC or other variables, while the latter means that the code might not work if _that_ class of warning is raised — since you can't use -Werror=something if you don't know that something exists.
I feel this really needs a patch for the devmanual. Could someone provide a patch even if it's a short one? I'm not the guy.
I can review but I won't touch the thing...
Created attachment 331540 [details, diff] text.xml.diff (In reply to comment #8) > I can review but I won't touch the thing... take this
aaany comment?
if QA is happy then I am happy too
QA, are you happy? :D
LGTM.
committed
