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.