Global compiler variables - Revision history

BlueHazzard: Add information for command line arguments

2023-03-28T23:05:59Z

Add information for command line arguments

← Older revision		Revision as of 23:05, 28 March 2023
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.

			== Command line arguments ==
			After revision [r13245] it is possible to use command line arguments to override and define global variables and set the current active set.
			* '-S' parameter for setting current active set via command line
			* '-D' parameter for defining/overriding user variable in form <tt>-D set.variable.member=value</tt> or <tt>-D variable.member=value</tt>


	==See also==		==See also==
	* [[Variable expansion]]		* [[Variable expansion]]

LETARTARE: /* Constraints on custom member */

2019-07-29T08:07:07Z

Constraints on custom member

← Older revision		Revision as of 08:07, 29 July 2019
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.		*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).		*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:		*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		**You may not define a variable by a value that references the same variable or any of its members

LETARTARE: /* Constraints on custom memeber */

2019-07-29T08:01:04Z

Constraints on custom memeber

← Older revision		Revision as of 08:01, 29 July 2019
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.		*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).		*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:		*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		**You may not define a variable by a value that references the same variable or any of its members

Alpha: Added "See also".

2011-10-08T14:59:32Z

Added "See also".

← 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]]

Artojon: edit category

2006-07-08T15:33:49Z

edit category

← Older revision		Revision as of 15:33, 8 July 2006
Line 1:		Line 1:
	[[Category:~~Application Development~~]]		[[Category:User Documentation]]
	== Synopsis ==		== 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.		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.

Thomas: /* Constraints */

2006-07-04T14:21:32Z

Constraints

← Older revision		Revision as of 14:21, 4 July 2006
Line 27:		Line 27:
	*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).		*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.
	*Variable and member values may contain <i>arbitrary</i> character sequences, subject to the following ~~two~~ constraints:		*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		**You may not define a variable by a value that references the same variable or any of its members
	**You may not define a member by a value that references the same member		**You may not define a member by a value that references the same member

Thomas: /* Constraints */

2006-07-04T14:20:24Z

Constraints

← Older revision		Revision as of 14:20, 4 July 2006
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.		*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).		*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 ~~generally~~, 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.
	*Variable and member values may contain <i>arbitrary</i> character sequences, subject to the following two constraints:		*Variable and member values may contain <i>arbitrary</i> character sequences, subject to the following two constraints:
	**You may not define a variable by a value that references the same variable or any of its members		**You may not define a variable by a value that references the same variable or any of its members

Thomas at 12:29, 4 July 2006

2006-07-04T12:29:35Z

← Older revision		Revision as of 12:29, 4 July 2006
Line 1:		Line 1:
	[[Category:Application Development]]		[[Category:Application Development]]
	== Synopsis ==		== 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.		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 ==		== 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''.		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.

			It is generally recommended to 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>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.		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.
			Beginning with revision 2664 (4 July 2006), Code::Blocks allows you to define custom variable members in addition to the builtin ones.


			[[Image:Gcv_ui.png]]


			== Constraints ==
			*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 generally, the behaviour for this case is undefined.
			*Variable and member values may contain <i>arbitrary</i> character sequences, subject to the following two constraints:
			**You may not define a variable by a value that references the same variable or any of its members
			**You may not define a member by a value that references the same member
			**You may not define a member or variable by a value that references the same variable or member through a cyclic dependency.
			Code::Blocks will detect the most obvious cases of recursive definitions (which may happen by accident), but it will not perform an excessive depth analysis of every possible abuse. If you enter crap, then crap is what you will get, you have been warned.

			<u>Examples:</u><br />
			defining <tt>wx.include</tt> as <tt>$(#wx)/include</tt> is redundant, but perfectly legal<br />
			defining <tt>wx.include</tt> as <tt>$(#wx.include)</tt> is illegal and will be detected by Code::Blocks<br />
			defining <tt>wx.include</tt> as <tt>$(#cb.lib)</tt> which again is defined as <tt>$(#wx.include)</tt> will create an infinite loop

	== Using Global Compiler Variables ==		== 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.		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.		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.

			== Variable Sets ==
			Sometimes, you want to use different versions of the same library, or you develop two branches of the same program. Although it is still possible to get around with a global compiler variable, it can become tedious. For this purpose, Code::Blocks supports variable <i>sets</i>. A variable set is an independent collection of variables identified by a name (set names have the same constraints as variable names).

			If you wish to switch to a different set of variables, you simply select a different set from the menu. Different sets are not required to have the same variables, and identical variables in different sets are not required to have the same values, or even the same custom members.

			Another positive thing about sets is that if you have a dozen variables and you want to have a new set with one of these variables pointing to a different location, you are not required to re-enter all this redundant data again. You can simply create a clone of your current set, this will duplicate all of your variables.

			Deleting a set also deletes all variables in that set (but not in another set). The "default" set is always present and cannot be deleted.

	== Custom Members Mini-Tutorial ==		== Custom Members Mini-Tutorial ==

Sethjackson at 20:48, 11 April 2006

2006-04-11T20:48:14Z

← Older revision		Revision as of 20:48, 11 April 2006
Line 1:		Line 1:
	[[Category:~~Code::Blocks features]]~~		[[Category:Application Development]]
	~~[[Category:~~Development]]
	== Synopsis ==		== 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.

Thomas: /* Names and Members */

2006-03-27T19:30:23Z

Names and Members

← Older revision		Revision as of 19:30, 27 March 2006
Line 13:		Line 13:
	The members <tt>dir</tt> and <tt>base</tt> resolve to the same value as the variable name uses without a member (alias).		The members <tt>dir</tt> and <tt>base</tt> resolve 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 mini tutorial ~~at end of page~~).		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>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.		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.