Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
cb_release_type and GCV's
Biplab:
--- Quote from: MortenMacFly on December 31, 2012, 04:04:37 pm ---I agree, but: We did that initially for combination of -s and -g to avoid forum noise because people complained they were not able to debug. I think this is a time-safer.
--- End quote ---
Thanks for the background.
--- Quote from: MortenMacFly on December 31, 2012, 04:38:28 pm ---
--- Quote from: jens on December 31, 2012, 04:22:26 pm ---But silently removing options without warning is not a good option in my opinion, even if they can not be used together like -s and -g.
--- End quote ---
I agreed to that already:
--- Quote from: MortenMacFly on December 31, 2012, 04:04:37 pm ---You are allowed to set these flags - if one is silently removed (which I didn't try to reproduce so far) that is the actual bug to me.
--- End quote ---
--- End quote ---
We have few options.
1) Close all such threads with a generic reply. Similar to whenever anybody asks general programming question.
2) Use a ListBox to group such conflicting options, so that only one such option can be selected. I remember some work was done earlier using wxPropGrid which allows us to do that.
3) Add an api (if not present) to mark conflicting options and warning users should they try to select them.
Alpha:
For the sake of discussion, here are some of my original thoughts from when I was writing this behaviour.
Options the specifically state in the documentation that they supersede one another (for example -O1 and -O2) will automatically remove the other. Options that cannot function together (-s and -g, multiple architecture selections) automatically remove the other.
Options that can coexist, but have, on occasion, brought complaints (debugging and optimization) trigger an AnnoyingDialog warning.
I am not saying this was correct reasoning, just that this was why I originally tried.
--- Quote from: Biplab on December 31, 2012, 04:59:44 pm ---3) Add an api (if not present) to mark conflicting options and warning users should they try to select them.
--- End quote ---
From a trunk build, try right-clicking on a flag, and selecting "Modify flag". Also read about two-thirds down this page.
thomas:
--- Quote ---(quote from GCC documenation)
--- End quote ---
The only real, observable strange effects are that sometimes you cannot break at a particular line (it will break a few lines further down) and that sometimes, examining a variable will only give "optimized out". Neither is really strange or unexpected in an optimized build. All in all, it works very, very well.
--- Quote ---forum noise
--- End quote ---
That's of course a good reason.
--- Quote ---more annoying dialogs, silently dropping options
--- End quote ---
Maybe a workable solution would be to change the respective option's color in the list view to red if it conflicts with another option. Possibly mark them both red, so one can see where the conflict is. Or, add a small status line at the bottom of the config dialog, which is usually empty/invisible, and shows info such as "Note: -O2 and -g may give unexpected results". No more than a single line, and no more than at most 10-12 words, ever.
In any case, silently dropping an option is something I consider "too smart". This would acceptable only if we add something like "build profiles" (a kind of dumbed down way of selecting options, like "debug build" or "fully optimized build" that lets the exact details of what to do to the IDE). As a general thing, however, it's not really acceptable.
MortenMacFly:
--- Quote from: thomas on December 31, 2012, 07:04:29 pm ---respective option's color in the list view to red if it conflicts with another option. Possibly mark them both red, so one can see where the conflict is. Or, add a small status line at the bottom of the config dialog, which is usually empty/invisible, and shows info such as "Note: -O2 and -g may give unexpected results". No more than a single line, and no more than at most 10-12 words, ever.
--- End quote ---
That would be a nice option because it permanent but doesn't affect the work flow.
--- Quote from: thomas on December 31, 2012, 07:04:29 pm ---As a general thing, however, it's not really acceptable.
--- End quote ---
I think for really stupid combinations like -g and -s it is - NEVER silently (this isn't acceptable, I agree), but with a message dialog and the ability to allow it anyways, even if it may be stupid. It has been similar like that a long time, btw. in terms of a message box appeared with a warning but not an option for an automatic correction - which would be new and not that bad I think.
Alatar:
--- Quote from: MortenMacFly on December 30, 2012, 07:32:55 am ---
The question is, what does C::B ask you to setup? I believe it will ask you to setup the "CB" variable and not cb.cflags. So it is still unclear to the user what needs to be done. IMHO even more unclear than it is now... or if renaming from "cb_release_type" to "cb_cflag" (note the underscore). Its not nice, but now people ask at least what they need to do - exactly what the GCV concept is for. With "cb.cflags" I guess most people will set it to "anything" to silence the message. If we find a way to avoid such mistakes, too - that would be nice.
--- End quote ---
Ideally we need some way to instruct GCV manager what it should ask (basic self-documentation for GCV). For example this may look like
$(#cb.build_flags:"Specify debug or optimisation flags to build CB")
When macros manager found such definition it should display Global Variable Editor dialog with specified text.
Unfortunately in current realisation macros manager don`t drop invalid part of definition and this string evaluated as
-O2:"Specify debug or optimisation flags to build CB")
So if we add such logic and define variables in this way, this will break building in old CB versions =(.
Second limitation is when macros manager found undefined GCV it prompt user to define it, but if it found undefined GCV`s member it silently replace it with empty string.
Navigation
[0] Message Index
[*] Previous page
Go to full version