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

Artojon: removed extra category

2006-11-11T18:49:26Z

removed extra category

Rathapolk at 16:36, 2 August 2006

2006-08-02T16:36:57Z

Mandrav: Categorized document

2006-07-14T08:48:59Z

Categorized document

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)

MortenMacFly: making headings

2006-07-14T06:56:55Z

making headings

MortenMacFly: Removed header (appeared twice)

2006-07-14T06:53:12Z

Removed header (appeared twice)

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.

@@ Line 78: / Line 78: @@
 == 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.
 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 :)
-''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 ===
@@ Line 102: / Line 112: @@
 [[User:Mandrav|Mandrav]] 04:42, 14 July 2006 (EDT)

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

@@ 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).
-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.''

← 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 :).

@@ Line 1: / Line 1: @@
-== The build order, projects and targets ==
+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 :).
-== Starting the build process ==
+= Build order =
-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.
+As you have probably guessed, Code::Blocks does not launch build commands at random but rather as a well thought out and prepared sequence. But first let's see what components are the subject of the build:
-== Using build scripts ==
+* '''Workspace''': contains one or more projects
-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).
+* '''Project''': contains one or more build targets. It also contains the project's files.
-== Using pre- and post build steps ==
+Let's break these subjects in sections and explain them in more detail.
-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.

@@ Line 1: / Line 1: @@
 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.
@@ 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.
 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.

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