Created attachment 328448 [details] Proposed patch for space checking at setup phase This is continuation of #440990. I agree that this could be just upstream bug, but at least portage should print some ewarn instead of simply failing. Or just strip all trailing spaces out. See patch attached for my suggestion how to implement the proper warning.
Don't put spaces at the start or end of those variables. It's still invalid. *** This bug has been marked as a duplicate of bug 440990 ***
No, it's not. 1) This is different bug - it's about missing warning or proper documentation 2) There is no mention of "you should not use trailing or initial spaces in CFLAGS, CXXFLAGS and LDFLAGS", nor in man make.conf, nor in man portage, nor in handboox. So spaces are perfectly valid and there much more oppotunities to hit this _bug_ even without using complex configurations with variables, like CFLAGS=" -O2 -pipe -march=native -mtune=native -floop-graphite-identity " This is perfectly valid example (following current syntax and documentation) and, in case anything won't work with such syntax, it should be forbidden or/and properly documented either in man make.conf /CFLAGS or in ebuild. Or, maybe, portage could just strip useless spaces out, but it's quite hard to define, which spaces are "useless".
Please file a new bug report if you want any documentation changed. *** This bug has been marked as a duplicate of bug 440990 ***
Why? So you can close it too? It's not up to me to decide, if it's worth changing documentation or it's ebuild bug, it's up to developers and therefore, I can't just fill a dozen bugs with all possible solutions and propositions for you, so you may just choose most relevant and close others. This bug summary is perfectly clear and correct. It says that ebuild _doesn't warn user about bad flags_ (not about "it doesn't compile"). If you still don't want to look into this issue yourself, please close it with proper resolution: nor INVALID (it's not invalid), nor DUPLICATE (it's not duplicate), but with WONTFIX (as it's what you are doing now). This _is_ a bug about documentation, about ebuild's one. And it's up to you to decide if it should be escalated to level of documentation, not me. And, if you decided that it should be done in documentation than, please, make your statement clear and sound, not like vague "please fill ... if you want any documentation changed" in your comment 3, so I may refer to it while filling new bug. I don't want any documentation changes, I just want to be warned in any way and I can't decide which way is more appropriate for developers. So, please, close it _again_ (if you still want to close it) with proper resolution and non-vague comment about how this issue should be resolved instead. If you can't decide that, please, pass this bug to someone who can. Thank you.
Because you've made a mess of this bug report. That patch isn't going in, but you may have a chance of getting the documentation changed, which would best go through another bug report. Now with all the back and forth here, there is way too much noise. If you want to get the docs fixed, then start with a clean bug report that we can address to the documentation people. *** This bug has been marked as a duplicate of bug 440990 ***
Also, look through all the INVALID/WONTFIX/DUPLICATE bugs that describe your exact problem with spaces at the end/beginning and extra spaces in the middle of the values of commonly used compiler/linker variables. This isn't the first time.
+local has_spaces=false + +for flags in {C,CXX,LD}FLAGS; do + local content= + + eval content=\"\${$flags}\" + + echo "${content}" | egrep -q '(^[[:space:]]|[[:space:]]$)' || continue + + eerror "$flags variable contain trailing or initial spaces: '$content'" + has_spaces=true +done + +${has_spaces} && die "boost-build could not be build with flags given" One of the first thing I have learned when looking into ebuilds and asking questions about it, is that ebuilds should never contains hacks or workarounds when such particular bug can possible be fixed upstream or in a better place. Thus this yields the following options to proceed: 1. File this parsing bug upstream so that they can fix it there. 2 Attempt to file a new bug to address the following suggestion you had: > Or, maybe, portage could just strip useless spaces out, but it's quite hard to define, which spaces are "useless". These two options are way more valuable than changing the ebuild, the former fixes it for every distro and the latter fixes it for everything that compiles; hacking the ebuild doesn't solve the actual problem.
Aaand, guess why? Because it's required to post 3 lengthy posts just to get information that: 1) Patch is not going in 2) It's not going in because it's too much common problem and it's useless to fix one ebuild and, finally 3) As it's so much common problem, it should be fixed on level of portage or at level of documentation, probably last way. 4) And as it should be done at level of documentation and/or portage, bug should be filled in appropriate category and it's summary should explicitly state complexity of this issue. 5) So, new bug should be filled with all this points listed in. Please also note that your first answer didn't referred correct solution to issue at all (and second answer was more like "shut up and go away"), so if it was your standard answer for all such issues than issue's current state is not a surprise. I know that you are volunteers and you have no obligation to actually do anything in any way, but, IMO, you guys should try not to see your users as enemies - it will help a lot for both sides. At least you will not be forced to close so much of same issues (unless you really-really love closing issues). BTW, it wasn't me who "made a mess" ;) I can't close with duplicate, you know. But anyway, thanks for that somehow clear and almost non-vague answer, that you finally given. That heroic social deed will be remembered among gentoo users forever. And probably, just in case, may lead to actual solution of this problem. Despite of your stubbornness and refusal to close this issue with proper resolution, I decided not to continue this "social adaptation for gentoo developers" course and leave this for your conscience. I'll fill new bug, though. Thank you for your patience.
(In reply to comment #7) > These two options are way more valuable than changing the ebuild, the former > fixes it for every distro and the latter fixes it for everything that > compiles; hacking the ebuild doesn't solve the actual problem. Unless this is sole problem. Upstream may just refuse to fix gentoo-specific bugs as they may just not support user-supplied CFLAGS (and maybe their README file even states that *FLAGS variables should not contain spaces). But, hopefully, it's not that case, but it should be clarified by wrangler anyway, That's the reason for all this noise ;) https://svn.boost.org/trac/boost/ticket/3630
