Difference between revisions of "The build process of Code::Blocks"

From Code::Blocks
m (Removed header (appeared twice))
m (making headings)
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.

Revision as of 06:56, 14 July 2006

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

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

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.

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

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. This happens for each file within each target and each projects whose compilation has been requested.