It is generally recommended to use the syntax $(#variable.include) instead of $(#variable)/include, as it provides additional flexibility and is otherwise exactly identical in functionality (see mini tutorial). However, a user can redefine them if another setup is desired. The members include and lib are by default aliases for base /include and base /lib, respectively. The member base resolves to the same value as the variable name uses without a member (alias). The Code::Blocks team provides a list of recommended variables for known packages. This way, the amount of information that the user needs to provide is minimised. Although you can choose anything for a variable name in principle, it is advisable to pick a known identifier for common packages. Names are freely definable, while some of the members are built into the IDE. Global compiler variables are structured every variable consists of a name and an optional member.

Global compiler variables in Code::Blocks are discriminated from per-project variables by a leading hash sign. No local layout information ever needs to be changed more than once. Global compiler variables allow you to set up a project once, and any number of developers using any number of different filesystem layouts will be able to compile and develop the project. The concept of global compiler variables is an unique new solution for Code::Blocks which addresses this problem.

If one does not pay attention, this can happen easily for example after changing a build flag to make a release build. In the case of project files, care must be taken to not accidentially commit a locally modified copy.

Working as a developer on a project which relies on 3rd party libraries involves a lot of unnecessary repetitive tasks, such as setting up build variables according to the local filesystem layout.

Codeblocks compiler problem