The build process of Code::Blocks - Revision history

Elzorro: /* Pre-build and post-build steps */

2008-08-04T21:19:46Z

Pre-build and post-build steps

← Older revision		Revision as of 21:19, 4 August 2008
Line 78:		Line 78:
	== Pre-build and post-build steps ==		== Pre-build and post-build steps ==
	These are commands that can be setup on project and/or target level. They are shell commands that e.g. copy files around or any other operation you can do with a usual OS system shell.		These are commands that can be setup on project and/or target level. They are shell commands that e.g. copy files around or any other operation you can do with a usual OS system shell.

			The variables specified in the article [[Variable expansion]] can be used in the scripts to get things like target output directory, project directory, target type and others.

	Here's a breakdown of the pre/post build steps execution order for an imaginary project with two targets (Debug/Release):		Here's a breakdown of the pre/post build steps execution order for an imaginary project with two targets (Debug/Release):
Line 94:		Line 96:
	I hope this is self-explaining :)		I hope this is self-explaining :)

			''NOTE: Pre-build steps are always ran. Post-build steps will run only if the project/target they 're attached to is not up-to-date (i.e. is going to be built). You can change this by selecting "Always execute, even if target is up to date" in the build options.''

	~~''NOTE: Pre-build steps are always ran.~~ Post-build ~~steps will run only if~~ the ~~project~~/~~target they 're attached to is not up-to-date~~ (~~i.e. is going to be built~~). ~~You can change this by selecting "Always execute, even if target is up to date~~" in ~~the build options~~.''		=== Script Samples ===
			Post-build script that copies the output file into the folder "C:\Program\bin" in Windows:
			cmd /c copy "$(PROJECT_DIR)$(TARGET_OUTPUT_FILE)" "C:\Program\bin"

			Execute the bash script "copyresources.sh" in Linux:
			/bin/sh copyresources.sh

			Create a new directory in the output directory:
			mkdir $(TARGET_OUTPUT_DIR)/data


Line 102:		Line 112:

	[[User:Mandrav\|Mandrav]] 04:42, 14 July 2006 (EDT)		[[User:Mandrav\|Mandrav]] 04:42, 14 July 2006 (EDT)

			[[User:Elzorro\|Elzorro]] 23:19, 4 August 2008 (CEST)

Artojon: removed extra category

2006-11-11T18:49:26Z

removed extra category

← Older revision		Revision as of 18:49, 11 November 2006
Line 1:		Line 1:
	~~[[Category:Code::Blocks Documentation]]~~
	[[Category:User Documentation]]		[[Category:User Documentation]]

Rathapolk at 16:36, 2 August 2006

2006-08-02T16:36:57Z

← Older revision		Revision as of 16:36, 2 August 2006
Line 35:		Line 35:
	Project dependencies are a simple way to tell Code::Blocks that a given project "depends" on another (in the same workspace, always).		Project dependencies are a simple way to tell Code::Blocks that a given project "depends" on another (in the same workspace, always).

	Thus imagine in your workspace you have a library project and an executable project which depends on the library. Then you could (and should) tell Code::Blocks about this ~~depndency~~. To do this, you select "Project->Properties" and click the "Project's dependencies.." button.		Thus imagine in your workspace you have a library project and an executable project which depends on the library. Then you could (and should) tell Code::Blocks about this dependency. To do this, you select "Project->Properties" and click the "Project's dependencies.." button.

	''Please notice that the dependency information is saved within the workspace file, not the project file as it is a dependency between two projects within a workspace.''		''Please notice that the dependency information is saved within the workspace file, not the project file as it is a dependency between two projects within a workspace.''

Mandrav: Categorized document

2006-07-14T08:48:59Z

Categorized document

← Older revision		Revision as of 08:48, 14 July 2006
Line 1:		Line 1:
			[[Category:Code::Blocks Documentation]]
			[[Category:User Documentation]]

	In this page, the build process is explained in detail. What goes on behind the scenes and "when" is covered. I hope it makes an interesting read :).		In this page, the build process is explained in detail. What goes on behind the scenes and "when" is covered. I hope it makes an interesting read :).

Mandrav: Reformatted and almost rewritten article (with original author's conscent)

2006-07-14T08:42:23Z

Reformatted and almost rewritten article (with original author's conscent)

Show changes

MortenMacFly: making headings

2006-07-14T06:56:55Z

making headings

← Older revision		Revision as of 06:56, 14 July 2006
Line 1:		Line 1:
			== The build order, projects and targets ==
	Code::Blocks has a strict build order. According to the project setup the targets of a project are build in the order from top to bottom (unless the build of a target is disabled in the options). Within the focus of a workspace the projects that belong to a workspace are usually build according to the target that has been selected.		Code::Blocks has a strict build order. According to the project setup the targets of a project are build in the order from top to bottom (unless the build of a target is disabled in the options). Within the focus of a workspace the projects that belong to a workspace are usually build according to the target that has been selected.
	Let's assume all projects in a workspace have the targets "Debug" and "Release". Furthermore the checkbox "Build this target with all" in each project's target options is enabled for all "Release" targets. Thus if as build target "Debug" is selected, all "Debug" targets of all projects will be build in the order as they appear. If a project has no "Debug" target it will be skipped.		Let's assume all projects in a workspace have the targets "Debug" and "Release". Furthermore the checkbox "Build this target with all" in each project's target options is enabled for all "Release" targets. Thus if as build target "Debug" is selected, all "Debug" targets of all projects will be build in the order as they appear. If a project has no "Debug" target it will be skipped.
Line 4:		Line 5:
	Please notice that you are not limited to this kind of target. Another target philosophy could be additional libraries that are required to complete the build process of a project. But the libraries could also be setup as own project within a workspace.		Please notice that you are not limited to this kind of target. Another target philosophy could be additional libraries that are required to complete the build process of a project. But the libraries could also be setup as own project within a workspace.

			== Dependencies between projects ==
	Now we had said that the build order for projects is as they appear in the workspace. This is generally true unless you setup project dependencies. A project dependency can be setup in project options. You simply select for a project on which other projects it depends. Thus imagine in your workspace you have a library project and an executable project which depends on the library. Then you could (and should) enable the dependency checkbox in the project options of the executable project.		Now we had said that the build order for projects is as they appear in the workspace. This is generally true unless you setup project dependencies. A project dependency can be setup in project options. You simply select for a project on which other projects it depends. Thus imagine in your workspace you have a library project and an executable project which depends on the library. Then you could (and should) enable the dependency checkbox in the project options of the executable project.
	Please notice that this information is saved within the workspace file, not the project file as it is a dependency between two projects within a workspace.		Please notice that this information is saved within the workspace file, not the project file as it is a dependency between two projects within a workspace.
	This in addition changes the order of how your projects are build. It was said that the general order is from top to bottom (for the selected target(s)). With dependencies this might change. If your executable project is at the top and the library at the bottom and the executable has been setup to depend on the library then first the library will be build and second the executable.		This in addition changes the order of how your projects are build. It was said that the general order is from top to bottom (for the selected target(s)). With dependencies this might change. If your executable project is at the top and the library at the bottom and the executable has been setup to depend on the library then first the library will be build and second the executable.

			== Starting the build process ==
	Before the actual build process starts (i.e. the compiler/linker commands start executing), a preprocessing step runs which generates all required command-lines. This step is necessary because it also caches much information making subsequent builds faster.		Before the actual build process starts (i.e. the compiler/linker commands start executing), a preprocessing step runs which generates all required command-lines. This step is necessary because it also caches much information making subsequent builds faster.

			== Using build scripts ==
	Another way to influence the build process are build scripts that can be attached on project- and target-level within the project setup. These scripts are in Squirrel and have defined entry points that are required to be implemented. The build scripts run in the preprocessing step mentioned before. Build scripts usually alter project/target options which are then added to the command line (in this step).		Another way to influence the build process are build scripts that can be attached on project- and target-level within the project setup. These scripts are in Squirrel and have defined entry points that are required to be implemented. The build scripts run in the preprocessing step mentioned before. Build scripts usually alter project/target options which are then added to the command line (in this step).

			== Using pre- and post build steps ==
	When this is done, Code::Blocks starts to actually execute build commands including so-called pre- and post-build steps. These commands that again can be setup on project- and target level. This could be scripts (or batch files if you prefer Windows) that e.g. copy files or any other operation you can do with a usual OS system script. So the command line has been computed, now the pre-build steps are executed, then the command line (the actual compile step) executes, after that the post-build steps are executed.		When this is done, Code::Blocks starts to actually execute build commands including so-called pre- and post-build steps. These commands that again can be setup on project- and target level. This could be scripts (or batch files if you prefer Windows) that e.g. copy files or any other operation you can do with a usual OS system script. So the command line has been computed, now the pre-build steps are executed, then the command line (the actual compile step) executes, after that the post-build steps are executed.
	This happens for each file within each target and each projects whose compilation has been requested.		This happens for each file within each target and each projects whose compilation has been requested.

MortenMacFly: Removed header (appeared twice)

2006-07-14T06:53:12Z

Removed header (appeared twice)

← Older revision		Revision as of 06:53, 14 July 2006
Line 1:		Line 1:
	~~The build processes of Code::Blocks~~

	Code::Blocks has a strict build order. According to the project setup the targets of a project are build in the order from top to bottom (unless the build of a target is disabled in the options). Within the focus of a workspace the projects that belong to a workspace are usually build according to the target that has been selected.		Code::Blocks has a strict build order. According to the project setup the targets of a project are build in the order from top to bottom (unless the build of a target is disabled in the options). Within the focus of a workspace the projects that belong to a workspace are usually build according to the target that has been selected.
	Let's assume all projects in a workspace have the targets "Debug" and "Release". Furthermore the checkbox "Build this target with all" in each project's target options is enabled for all "Release" targets. Thus if as build target "Debug" is selected, all "Debug" targets of all projects will be build in the order as they appear. If a project has no "Debug" target it will be skipped.		Let's assume all projects in a workspace have the targets "Debug" and "Release". Furthermore the checkbox "Build this target with all" in each project's target options is enabled for all "Release" targets. Thus if as build target "Debug" is selected, all "Debug" targets of all projects will be build in the order as they appear. If a project has no "Debug" target it will be skipped.

MortenMacFly: First version of the article, no formatting yet, just content.

2006-07-14T06:52:42Z

First version of the article, no formatting yet, just content.

New page

The build processes of Code::Blocks

Code::Blocks has a strict build order. According to the project setup the targets of a project are build in the order from top to bottom (unless the build of a target is disabled in the options). Within the focus of a workspace the projects that belong to a workspace are usually build according to the target that has been selected.
Let's assume all projects in a workspace have the targets "Debug" and "Release". Furthermore the checkbox "Build this target with all" in each project's target options is enabled for all "Release" targets. Thus if as build target "Debug" is selected, all "Debug" targets of all projects will be build in the order as they appear. If a project has no "Debug" target it will be skipped.
The same applied to the "Release" target. If "All" is selected this would be the same in this example because we had enabled "Build this target with all" only for the "Release" targets. If we had enabled this checkbox for the "Debug" targets, too then build "All" would build both, the "Debug" and the "Release" targets of each project.
Please notice that you are not limited to this kind of target. Another target philosophy could be additional libraries that are required to complete the build process of a project. But the libraries could also be setup as own project within a workspace.

Now we had said that the build order for projects is as they appear in the workspace. This is generally true unless you setup project dependencies. A project dependency can be setup in project options. You simply select for a project on which other projects it depends. Thus imagine in your workspace you have a library project and an executable project which depends on the library. Then you could (and should) enable the dependency checkbox in the project options of the executable project.
Please notice that this information is saved within the workspace file, not the project file as it is a dependency between two projects within a workspace.
This in addition changes the order of how your projects are build. It was said that the general order is from top to bottom (for the selected target(s)). With dependencies this might change. If your executable project is at the top and the library at the bottom and the executable has been setup to depend on the library then first the library will be build and second the executable.

Before the actual build process starts (i.e. the compiler/linker commands start executing), a preprocessing step runs which generates all required command-lines. This step is necessary because it also caches much information making subsequent builds faster.

Another way to influence the build process are build scripts that can be attached on project- and target-level within the project setup. These scripts are in Squirrel and have defined entry points that are required to be implemented. The build scripts run in the preprocessing step mentioned before. Build scripts usually alter project/target options which are then added to the command line (in this step).

When this is done, Code::Blocks starts to actually execute build commands including so-called pre- and post-build steps. These commands that again can be setup on project- and target level. This could be scripts (or batch files if you prefer Windows) that e.g. copy files or any other operation you can do with a usual OS system script. So the command line has been computed, now the pre-build steps are executed, then the command line (the actual compile step) executes, after that the post-build steps are executed.
This happens for each file within each target and each projects whose compilation has been requested.