The code style used to fix this looks bizarre!
- src/sdk/compileroptions.cpp (fixes bug that enabled wrong options with just linker flags. Just don't search for empty options)
... that was a hot fix actually xD
I use this style from time to time.. but wouldn't have recommended it this way for the patch... it's missing at least a line feed
But this change is necessary... until the @note is solved to not add empty options... (linker only options for example conflict a bit... took me a while to find the cause. Still not sure if it's fixed once and for all... I don't remember a recent issue though)
The options parser should be improved anyway... working with MSVC showed me again some of it's flaws.. such as that the order in which options appear are of importance... "/Zi /debug" is seen by Code::Blocks, but not "/debug /Zi" or even "/Zi", "/debug" (single, independent options not set as a "single option" even though their order is correct)
The parser also requires a new attribute... "dependencies"... enabling this options does not only disable X but also enables Y (disable kind of works, but enable is simply missing)
About the LTO stuff: For me we need a better solution. There is no need to specify the -O flag twice. It should automatically replicate it in the linker settings when -flto is specified. [...] If I haven't read your description I wouldn't be able to guess that the O flags are linked to the LTO flag.
you're basically right... but hard to implement and it's also hard to still allow freedom. (like I say on next quote)
For me it's actually easier to find LTO settings... would prefer such "grouping" more often. It's hard to follow pure lines of text without anything you can use to determine your current position^^ (or in case of optimizations, group them to easily see what's what.)
And I know that you can select categories... but that takes longer then to read the list at once.. (if you're enabling settings from different categories)
p.s. thank you for making me read the LTO's help agian, now my LTO builds are faster (as expected) than non LTO builds. In the past they have been twice as slow. It seems that the -O flag in the linker settings is really important:)
Not just "really important", they are all that counts
-O on compile time is (currently) useless... I guess it might be even better to not use it there as I guess it'll speed up the compile time.. what's the reason to optimize first, when that isn't used anyway?
But I'm not totally sure and don't know of reasons why someone might need also to optimize on compile time as well, so I'm allowing both.