Global compiler variables - Revision history

BlueHazzard: Add information for command line arguments

2023-03-28T23:05:59Z

Add information for command line arguments

LETARTARE: /* Constraints on custom member */

2019-07-29T08:07:07Z

Constraints on custom member

LETARTARE: /* Constraints on custom memeber */

2019-07-29T08:01:04Z

Constraints on custom memeber

Alpha: Added "See also".

2011-10-08T14:59:32Z

Added "See also".

Artojon: edit category

2006-07-08T15:33:49Z

edit category

Thomas: /* Constraints */

2006-07-04T14:21:32Z

Constraints

Thomas: /* Constraints */

2006-07-04T14:20:24Z

Constraints

Thomas at 12:29, 4 July 2006

2006-07-04T12:29:35Z

Sethjackson at 20:48, 11 April 2006

2006-04-11T20:48:14Z

Thomas: /* Names and Members */

2006-03-27T19:30:23Z

Names and Members

@@ Line 72: / Line 72: @@
 This is where the true power of global user variables is unveiled. When defining the value of the <tt>#boost</tt> variable, you go one step further than usual. You define the member <tt>include</tt> as <tt>C:\Boost\include\boost-1_33_1\boost</tt> and the member <tt>lib</tt> as <tt>C:\Boost\lib</tt>, respectively.
 Your projects using <tt>$(#boost.include)</tt> and <tt>$(#boost.lib)</tt> will magically work on every PC without any modifications. You don't need to know why, you don't want to know why.
 ==See also==
 * [[Variable expansion]]

@@ Line 26: / Line 26: @@
 *Both set and global compiler variable <i>names</i> may not be empty, must not contain white space, must start with a letter and must consist of alphanumeric characters. Cyrillic or Chinese letters are <i>not</i> alphanumeric characters.<br />If Code::Blocks is given invalid character sequences as name, it may replace them without asking.
 *Every variable requires its base to be defined. Everything else is optional, but the base is absolutely mandatory. If you don't define a variable's base, it will not be saved (no matter what other fields you have defined).
-*You may not define a custom member that has the same name as a builtin member. Currently, the custom member will overwrite the builtin member, but in general, the behaviour for this case is undefined. If <tt>'libext'</tt> is a custom member we can only write <tt>$(#variable.libext)</tt> and not <tt>$(#variable)/.libext</tt>.
+*You may not define a custom member that has the same name as a builtin member. Currently, the custom member will overwrite the builtin member, but in general, the behaviour for this case is undefined. If <tt>'libext'</tt> is a custom member we can only write <tt>$(#variable.libext)</tt> and not <tt>$(#variable)/libext</tt>.
 *Variable and member values may contain <i>arbitrary</i> character sequences, subject to the following three constraints:
 **You may not define a variable by a value that references the same variable or any of its members

@@ Line 26: / Line 26: @@
 *Both set and global compiler variable <i>names</i> may not be empty, must not contain white space, must start with a letter and must consist of alphanumeric characters. Cyrillic or Chinese letters are <i>not</i> alphanumeric characters.<br />If Code::Blocks is given invalid character sequences as name, it may replace them without asking.
 *Every variable requires its base to be defined. Everything else is optional, but the base is absolutely mandatory. If you don't define a variable's base, it will not be saved (no matter what other fields you have defined).
-*You may not define a custom member that has the same name as a builtin member. Currently, the custom member will overwrite the builtin member, but in general, the behaviour for this case is undefined.
+*You may not define a custom member that has the same name as a builtin member. Currently, the custom member will overwrite the builtin member, but in general, the behaviour for this case is undefined. If <tt>'libext'</tt> is a custom member we can only write <tt>$(#variable.libext)</tt> and not <tt>$(#variable)/.libext</tt>.
 *Variable and member values may contain <i>arbitrary</i> character sequences, subject to the following three constraints:
 **You may not define a variable by a value that references the same variable or any of its members

← Older revision		Revision as of 14:59, 8 October 2011
Line 72:		Line 72:
	This is where the true power of global user variables is unveiled. When defining the value of the <tt>#boost</tt> variable, you go one step further than usual. You define the member <tt>include</tt> as <tt>C:\Boost\include\boost-1_33_1\boost</tt> and the member <tt>lib</tt> as <tt>C:\Boost\lib</tt>, respectively.		This is where the true power of global user variables is unveiled. When defining the value of the <tt>#boost</tt> variable, you go one step further than usual. You define the member <tt>include</tt> as <tt>C:\Boost\include\boost-1_33_1\boost</tt> and the member <tt>lib</tt> as <tt>C:\Boost\lib</tt>, respectively.
	Your projects using <tt>$(#boost.include)</tt> and <tt>$(#boost.lib)</tt> will magically work on every PC without any modifications. You don't need to know why, you don't want to know why.		Your projects using <tt>$(#boost.include)</tt> and <tt>$(#boost.lib)</tt> will magically work on every PC without any modifications. You don't need to know why, you don't want to know why.
		+
		+	==See also==
		+	* [[Variable expansion]]

@@ Line 1: / Line 1: @@
-[[Category:Application Development]]
+[[Category:User Documentation]]
 == Synopsis ==
 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. In the case of project files, care must be taken to not accidentially commit a locally modified copy. If one does not pay attention, this can happen easily for example after changing a build flag to make a release build.

@@ Line 1: / Line 1: @@
 [[Category:Application Development]]
 == Synopsis ==
-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. 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. In the case of project files, care must be taken to not accidentially commit a locally modified copy. If one does not pay attention, this can happen easily for example after changing a build flag to make a release build.
 The concept of global compiler variables is an unique new solution for Code::Blocks which addresses this problem.
-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. No local layout information 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. No local layout information ever needs to be changed more than once.
 == Names and Members ==
 Global compiler variables in Code::Blocks are discriminated from [[per-project variables]] by a leading hash sign. Global compiler variables are structured; every variable consists of a ''name'' and an optional ''member''.
-Names are freely definable, while the member structure is built into the IDE. Although you can choose anything for a variable name in principle, it is advisable to pick a known identifier for common packages. This way, the amount of information that the user needs to provide is minimised. The Code::Blocks team provides a [[Recommended global variables|list of recommended variables]] for known packages.
+Names are freely definable, while some of the members are built into the IDE. Although you can choose anything for a variable name in principle, it is advisable to pick a known identifier for common packages. This way, the amount of information that the user needs to provide is minimised. The Code::Blocks team provides a [[Recommended global variables|list of recommended variables]] for known packages.
-The members <tt>dir</tt> and <tt>base</tt> resolve to the same value as the variable name uses without a member (alias).
+The member <tt>base</tt> resolves to the same value as the variable name uses without a member (alias).
-The members <tt>include</tt> and <tt>lib</tt> are by default aliases for ''base''<tt>/include</tt> and ''base''<tt>/lib</tt>, respectively. However, a user can redefine them if another setup is desired. It is recommended to ''always'' use the syntax <tt>$(#variable.include)</tt> instead of <tt>$(#variable)/include</tt>, as it provides additional flexibility and is otherwise exactly identical in functionality (see [[Global_compiler_variables#Custom_Members_Mini-Tutorial|mini tutorial]]).
+The members <tt>include</tt> and <tt>lib</tt> are by default aliases for ''base''<tt>/include</tt> and ''base''<tt>/lib</tt>, respectively. However, a user can redefine them if another setup is desired.
 The members <tt>cflags</tt> and <tt>lflags</tt> are empty by default and can be used to provide the ability to feed the same consistent set of compiler/linker flags to all builds on one machine.
 == Using Global Compiler Variables ==
-All you need to do to start using global compiler variables is to put them in your project!
+All you need to do to start using global compiler variables is to put them in your project! Yes, it is really that easy.
 When the IDE detects the presence of an unknown global variable, it will prompt you to enter its value. The value will be saved in your settings, so you never need to enter the information twice.
@@ Line 30: / Line 52: @@
 The above image shows both per-procect and global variables. <tt>WX_CFG</tt> is defined in the project, but <tt>WX</tt> is a global user variable.
 == Custom Members Mini-Tutorial ==