| Summary: | Additional checks for sanity of user-supplied *FLAGS variables in make.conf | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Petr Polezhaev <NightNord> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=442054 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
There is well known issue with badly written build systems which are expecting space to be mandatory separator for tokens in *FLAGS variables. Namely boost-build (but many others, including hand-written). In many cases extra spaces and, especially, new line characters may confuse build systems and lead to strange errors or, which is worse, to silently ignoring user's flags. Proper separation of "extra spaces" from not "extra spaces" in automatic way could not be possible, but, at least, simple cases like trailing or initial spaces, tabs and new lines characters are possible to detect. As example of such variable: CFLAGS=" -pipe -O2 -march=native -mtune=native -floop-graphite-identity " As misbehavior of build-system in case of for such formatted variables are upstream bugs, I suggest not to try auto-fix this issues, but simply warn users about possible problems with ability to disable warning for developers/users who want to test software. Please refer #441866 comment 5 and 6 by Jeroen Roovers and consult him for his vast knowledge about this issue.