cb_release_type and GCV's

[Alatar]

I think this is bad idea to use this GCV - it`s not intuitive. The variable should be named something like "cb_debug_build_flags". Alternatively this may be variable "cb_release_type" that may be "Release" or "Debug" and in the project file evaluated with script like ('[[if (#cb_release_type == "Debug") print(_T("-g")); else print(_T("-O2"));]]).
BTW should it be custom field of more generic variable (${#cb.release_type})?

Edit: Splitting topic and renaming title.

[thomas]

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.

[MortenMacFly]

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

As GCV's also work in a way like used here, why should we not allow it and limit ourselves to path's only? Yes, its maybe contrary to what is was intended to be - but so what? I've used it like that since the introduction of GCV's. For example, before we had the "auto-prefix/postfix" feature, I was using a GCV to define an executable extension, so I could write/use ".bins\myapp.$(#os.appext)". "os" here is/was a GCV w/o a valid base path, too. But I used the user / custom fields just fine for extensions and prefixes across platforms.

In the end its named Global Compiler Vars - not Path's... so we wouldn't even need to change the name to just allow what if can do more for devs. ;-)

[thomas]

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.

However, the base value of a GCV implicitly has path semantics, because the builtin relative members such as $#var.include or $#var.lib expand to ($#var)+path_sep+"include" or ($#var)+path_sep+"lib", respectively. That is, unless you explicitly specify a different value.

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.

[ollydbg]

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).

[Jenna]

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.

That's not 100% correct.
The base-path is flagged as invalid, that was introduced to avoid noise about empty GCV's (if I remember correctly), but just using the cflags or whatever, without a valid base-path works fine.
So $(#cb.cflags) seems to be the most natural way to use a GCV here.

[MortenMacFly]

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.

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.

[Biplab]

Is it too difficult to use few mouse clicks to add -g or -O2 at Project Build Options?

A GCV for this purpose is an overkill and confuses a lot of peoples. In my opinion this GCV is unnecessary and should be removed.

[thomas]

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 

Dunno, I'm not bothered either way. Maybe an environment variable would do, too (instead of a GCV). You can set it if you want, and otherwise, nothing will happen.

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.

[MortenMacFly]

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.

[thomas]

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.

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.

[oBFusCATed]

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.

[Alpha]

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.

[Jenna]

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.

It does the ame in both directions with an annoying dialog.
I don't think it's a real problem, maybe the message shoud just say, that it might be a problem and not saym that it is not a good thing to do so.

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).
This should have an annoying dialog and a cancel option, in my opinion.

[Biplab]

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...

I got your point.

Now the question is do we want to change the way C::B is being compiled? That means a Pure Debug build or a Pure Release build. In that case update.bat should be modified accordingly.

Anyway this approach is better. As GCC documentation says, mixing -g and -O flags can produce surprising results.

Quoted from http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html -

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.

[MortenMacFly]

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. ;-)

[Biplab]

I just tried to compile C::B by defining -g -O2 together. GCC didn't emit any warnings. I'm using C::B-12.11-MinGW + trunk source.

Code

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

What is the actual warning message that you are getting?

[Jenna]

You get a warning, if you set it via build options.

[Biplab]

You get a warning, if you set it via build options.

Sorry, I did that via Project > Build Options. But I'm not getting any warning. Build goes on smoothly.

[Jenna]

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.

[Biplab]

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.

Ok, I was prompted with that warning. Thanks for showing me the solution.


But I second Thomas' opinion.

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.

There is no need to make IDE too smart. There are tons of ways to warn users about bad coding / compilation options. Are we going to implement them all?

We can start by warning users who write unnecessarily complex Macros in C by writing a parser to analyze code on the fly and popping up an Annoying Dialog box. How about implementing a warning about the compiler options Jens explained earlier-

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.

[MortenMacFly]

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.

So yes - don't make the IDE too smart but also no - don't make it that simple that we need to answer the same stupid questions in the forums over and over again. Remember: A lot AnnoyingDialogs, including this dialog itself were/was implemented to avoid such scenarios.

What I can also imagine is that we extend the AnnoyingDialog for experts: So that in the (global) settings you have one global option to always turn off these messages. Then, assuming AnnoyingDialogs are for noobs only we could make us happy with a single option.

[Jenna]

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.
In this case an annoying dialog makes much more sense, than when using -g and -O2 together, which (in general) works.

[MortenMacFly]

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.

[MortenMacFly]

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.
Then - when switching this option to "on", show an AD that you may miss some interesting stuff...

[Biplab]

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.

Thanks for the background.

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.

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.

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.

[thomas]

(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 noise

That's of course a good reason.

more annoying dialogs, silently dropping options

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]

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.

[Alatar]

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.

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.