Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

cb_release_type and GCV's

(1/6) > >>

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:

--- Quote from: Alatar on December 13, 2012, 07:50:00 pm ---I think this is bad idea to use this GCV - it`s not intuitive.
--- End quote ---
It's conceptually wrong to use $#cb_release_type in such a way, even if it works.


--- Quote ---BTW should it be custom field of more generic variable (${#cb.release_type})?
--- End quote ---
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:

--- Quote from: thomas on December 29, 2012, 10:10:16 am ---The correct thing to use would be e.g. $#cb.cflags or $#cb.build_flags.

--- End quote ---
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:

--- Quote ---OK - but what path do you set then? A GCV w/o a valid default field entry, maybe a path, is flagged as invalid.
--- End quote ---
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).



--- Quote ---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?
--- End quote ---
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:

--- Quote from: thomas on December 29, 2012, 01:06:34 pm ---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.

--- End quote ---
I agree with thomas. I personally do not like such kind of variables(cb_build_type).

Navigation

[0] Message Index

[#] Next page