I was surprised to see that when emerging eix, it had USE flags for optimization and strong-optimization with descriptions stating they simply enabled CFLAGS. CFLAGS should be set in make.conf, the environment, or other usual places and respected as-is, not enabled by USE flags. For anyone interested, the implicated area of configure.ac is around line 220-270.
upstream's desire to enable them by default. Would you prefer that instead? I think not. I'll close this bug as INVALID because you didn't state a reason for opening.
As qa we don't agree with this approach. Every package must obey user set flags no matter what upstream says. Only expectations are hard mathematic dependant apps where more optimalizations might be needed, but this is not case for this one. So fix it in ebuild so it ALWAYS obey the flags.
(In reply to comment #2) > As qa we don't agree with this approach. > > Every package must obey user set flags no matter what upstream says. > > Only expectations are hard mathematic dependant apps where more optimalizations > might be needed, but this is not case for this one. > > So fix it in ebuild so it ALWAYS obey the flags. > It does "ALWAYS obey the user's flags", the USE flags add extra opts per upstream's decision. I had a long chat with the proxy-maintainer about it (also upstream) Again, closing as this bug is pointless.
It isn't pointless, and it would be nice if you could try to understand the confusion before closing the bug. I think I now understand what those use flags do after looking at it for a minute, and I think the names or explanations should be updated to explain them better. As I understand it, these flags do not touch existing CFLAGS, and not having them enabled does not strip any CFLAGS, but by enabling them they will enabled a bunch of optimizations that the user may not have, right? That isn't what the first reading of the explanation jumped out at me and said, especially given their names. I'd suggest changing the names and explanations so its clear these only supplement CFLAGS the user may have, and not having it set doesn't "disable optimizations".
(In reply to comment #4) > As I understand it, these flags do not touch existing CFLAGS, and not having > them enabled does not strip any CFLAGS, but by enabling them they will enabled > a bunch of optimizations that the user may not have, right? That isn't what > the first reading of the explanation jumped out at me and said, especially So the word: "Add" in the description means the same as 'strip' or 'disable' to you?? I think the descriptions are fine now. But, none-the-less, I will add some more words tonight when my commit host is online. > given their names. I'd suggest changing the names and explanations so its > clear these only supplement CFLAGS the user may have, and not having it set > doesn't "disable optimizations".
Sorry for my late reply, I have almost no time these days. (In reply to comment #4) > As I understand it, these flags do not touch existing CFLAGS, and not > having them enabled does not strip any CFLAGS, but by enabling them > they will enabled a bunch of optimizations that the user may not have, > right? Yes: If the flags are disabled (which is the default), nothing is changed, and if the flags are enabled, there may be added certain CXXFLAGS (if the user has not already enabled them and if some tests suggests that the toolchain will handle them well.) My (I am the upstream maintainer) reason to add certain CXXFLAGS is that I have taken care e.g. to avoid type punning in the code so that e.g. -fstrict-aliasing should not be able to break something; if it does, some unintended type punning happened, and this I consider as a bug in the code which should be fixed. Similar for other flags. I agree with the recommendation to the user to not enable "ricer" flags, but then in a sense it is upstream's responsibility to decide about them: In fact, usually only upstream knows all project code well enough to decide which of these are actually safe for the particular project. The usually valid argument that these flags may cause problems does not apply here, since if adding some of these flags should really cause problems, this only *reveals* an existing bug in the code: If there really should be such bugs, I would like to know about them (having unknown bugs can also be a security issue). I admit that in rare cases, some of the added flags can reveal a compiler bug instead of a bug in the code, but then to know about it won't hurt either. Moreover, I always test with these flags before releasing a new version. An enterprise user for which a misbehavior might have extremely serious consequences should be sane enough to not enable a USE-flag called "strong-optimization" anyway... > That isn't what the first reading of the explanation jumped out at me > and said, especially given their names. Maybe my English is too bad, but if the description for a USE-flag says that it "adds CFLAGS", then I would expect that not enabling this flag means that it does "not add CFLAGS" which is what is happening. Of course, I won't protest if the latter is stated explicitly. Thinking about it, it also won't hurt to point out in the description that enabling these flags *might* trigger hidden bugs.
metadata.xml is updated. Thanks for the input, Martin.
