View source for Code::Blocks variable types synthesis

[[Category:User Documentation]]
You will find here the different variable types available in Code::Blocks and when/how to use them.

== Environment Variables plugin ==
These are system wide and can be set/overridden by the [[Environment Variables plugin|EnvVars plugin]]. It's helpful if your e.g. have another build systems besides C::B that uses environment variables (like Makefiles). This way you can "share" this technology. The EnvVars plugin allows to setup different EnvVars sets which you can activate and/or refer to within [[Per-project variables|per-project]] settings. This might be useful for e.g. platform specific settings or library path variables (under Linux).

== Custom Variables under Global Compiler ==
These are helpful to e.g. quickly change a path for a compiler suite. For example: You have gcc 4.2.0 and gcc 3.4.5 installed. They all have the same path structure so if you setup the main path to the executables as e.g "D:\Devel\GCC$(GCC_VER)" and additional include/lib "D:\Devel\GCC$(GCC_VER)\include"/"D:\Devel\GCC$(GCC_VER)\lib" folders as you can easily switch between both compilers by just changing the custom variable. This would (of course) apply to *all* projects that use this very GCC compiler.

== Custom Variables under Project Build Options ==
These are very helpful if you want to compile your project against two compilers as stated above. You can have two targets with different compiler versions that both refer to one compiler setup but only differ e.g. in the path setup then. In addition you can easily append a "d" to libs for the debug version, e.g. wxmsw26u'''d''', an "u" for a unicode build, e.g. wxmsw26'''u'''d and/or a version string for a specific library version, e.g. wxmsw'''26'''ud. A library entry in the linker setup that incorporates all three examples would look like this:
<PRE>wxmsw$(WX_VER)$(WX_UNICODE)$(WX_DEBUG)</PRE>. Now you could setup the compiler variabes as following:
<PRE>
WX_VER=26
WX_DEBUG=d
WX_UNICODE=u
</PRE>
to active the unicode, debug v2.6 library name of wxWidgets, named <PRE>wxmsw26ud</PRE>
Notice that you can leave custom variables blank, thus if you leave WX_DEBUG blank you receive the non-debug name <PRE>wxmsw26u</PRE> (You could also just omit the setup of the custom variable at all.)<BR>
The values are being overridden in the order of details - compiler custom variables are overridden by project CV's and project CV's are overridden by target CV's. It only makes sense that way...

== Where does Global variables fall in this order of precedence? ==
These variables have a very special meaning. In contrast to all others if you setup such a variable and share your project file with others that have *not* setup this GV C::B will ask the user to setup the variable. This is a very easy way to ensure the "other developer" knows what to setup easily. C::B will ask for all path's usually necessary.<br>
For a detailed explanation please refer to the [[Global compiler variables]] page.