I think this is bad idea to use this GCV - it`s not intuitive.It's conceptually wrong to use $#cb_release_type in such a way, even if it works.
BTW should it be custom field of more generic variable (${#cb.release_type})?That. Global uservars were designed in a struct-like manner with the base name being the default value (presumably a directory), which the builtin base-relative members default to. In addition, there exist non-base-relative builtin members intended for compiler flags (functionally identical in every manner), and user fields that can be anything.
The correct thing to use would be e.g. $#cb.cflags or $#cb.build_flags.OK - but what path do you set then? A GCV w/o a valid default field entry, maybe a path, is flagged as invalid. Also, IMHO a GCV does not necessarily need to have a valid path at all. Think about if you just want to declare compiler flags, just as you mentioned
OK - but what path do you set then? A GCV w/o a valid default field entry, maybe a path, is flagged as invalid.The cb variable is to point to the location of the Code::Blocks SDK by convention. That's what was agreed upon some years ago anyway (to my knowledge, nobody ever used it anywhere).
Also, IMHO a GCV does not necessarily need to have a valid path at all. [...] why should we not allow it and limit ourselves to path's only?GCVs are not limited to being paths. No such thing was implied.
If you set $#cb_build_type = -g then $#cb_build_type.include will automatically be defined as -g/include, which does not really make sense.I agree with thomas. I personally do not like such kind of variables(cb_build_type).
That's not 100% correct.The correct thing to use would be e.g. $#cb.cflags or $#cb.build_flags.OK - but what path do you set then? A GCV w/o a valid default field entry, maybe a path, is flagged as invalid.
So $(#cb.cflags) seems to be the most natural way to use a GCV here.If it is really that simple to make you happy - go ahead. I thought you want to change the whole thing. I don't mind if we use the a member like ".cflags" instead. If the latter makes it more clear - do a global search and replace in *.cbp files and go for it.
Is it too difficult to use few mouse clicks to add -g or -O2 at Project Build Options?Not for me, because I've got both of them enabled system-wide anyway 8)
Is it too difficult to use few mouse clicks to add -g or -O2 at Project Build Options?Yes, if you think about the whole C::B workspace with ~30+ projects. Its not just "a few" mouse clicks then. This was the actual driver for doing that. The GCV is actively applied to all projects, including tools, contrib plugins and so on...
But I don't see any hindrance of simply setting -g -O2 in the project by default, either. Really, this works fine. There's no compelling reason not to optimize and having debug symbols. Not with GCC, anyway.Well C::B will complain then, at least.
Well C::B will complain then, at least.My version doesn't (at least not in the global options, might be different for per-project settings). But if it does, that is an example of needless stupidity.
So what was I saying... if Code::Blocks complains about that combination, we have a bug that needs to be fixed.Try to enable -g after you've enabled -O2 and you'll see the warning.
But I don't see any hindrance of simply setting -g -O2 in the project by default, either. Really, this works fine. There's no compelling reason not to optimize and having debug symbols. Not with GCC, anyway.I would prefer optimization not be a forced default because currently, I work on lower powered computers, so the additional (re)compile time is noticeable for me.
It does the ame in both directions with an annoying dialog.So what was I saying... if Code::Blocks complains about that combination, we have a bug that needs to be fixed.Try to enable -g after you've enabled -O2 and you'll see the warning.
Is it too difficult to use few mouse clicks to add -g or -O2 at Project Build Options?Yes, if you think about the whole C::B workspace with ~30+ projects. Its not just "a few" mouse clicks then. This was the actual driver for doing that. The GCV is actively applied to all projects, including tools, contrib plugins and so on...
GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values are already at hand; some statements may execute in different places because they have been moved out of loops.
Well this should be the actual warning that comes when you enable optimisations with debugging symbols in the annoying dialog. ;-)QuoteGCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values are already at hand; some statements may execute in different places because they have been moved out of loops.
mingw32-g++.exe -O2 -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\bindings -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Isdk\wxpropgrid\include -Isdk\mozilla_chardet\src -c D:\DevTools\trunk\src\sdk\cbdebugger_interfaces.cpp -o .objs\sdk\cbdebugger_interfaces.o
You get a warning, if you set it via build options.
I just read, that you use 12.11, but this comes with trunk after the release, as far as I know.
An annoying dialog pops up, immediately when you set the second option.
But if it does, that is an example of needless stupidity.
I'm always saying: Don't make things too smart, because too fucking smart soon becomes stupid. There is no sane reason for Code::Blocks to complain. It looks like you're trying to write a letter. Do you want to use the letter template? Wait a moment...
So what was I saying... if Code::Blocks complains about that combination, we have a bug that needs to be fixed.
What is worse: if you have -g set and also switch -s on (what is in fact an error), -g will be removed silently without any warning (and vice versa).
There could be numerous other examples. Do we need them? In my opinion we do not.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. So I wouldn't generally never warn, but warn in cases that safe us time. If the combination -02 and -g leads to cases where we are bugged in the forums I'd rather leave it as it is. I never tried to debug optimised code, but I recall that already now we have forum posts saying that the debugger does not stop at a certain BP which may have its roots in optimised code. Also remember: You are allowed to set these flags - if one is silently removed (which I didn't try to reproduce so far) that that is the actual bug to me. And this is also where "too smart" starts for me: At the time the IDE doesn't allow you to do for not good reason and bugs you over an over w/o the ability to turn it off.
We did that initially for combination of -s and -g to avoid forum noise because people complained they were not able to debug.
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.I agreed to that already:
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.
In this case an annoying dialog makes much more sense, than when using -g and -O2 together, which (in general) works.For me it makes sense in both cases, as both can lead to unexpected behaviour which is worth a warning... but one you can easily disable as an expert. Remember: A lot classes / students use our IDE and not many - even way less experts. So again: Lets to a global "never show AnnoyingDialogs" option, and check all AD's if they are really unimportant for experts.
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.
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.I agreed to that already: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.
3) Add an api (if not present) to mark conflicting options and warning users should they try to select them.From a trunk build, try right-clicking on a flag, and selecting "Modify flag". Also read about two-thirds down this page (http://wiki.codeblocks.org/index.php?title=Compiler_options_file).
(quote from GCC documenation)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.
forum noiseThat's of course a good reason.
more annoying dialogs, silently dropping optionsMaybe 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.
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.That would be a nice option because it permanent but doesn't affect the work flow.
As a general thing, however, it's not really acceptable.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.
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.