Programming Reference:Project Settings - Revision history

Mellinger at 13:41, 26 April 2011

2011-04-26T13:41:44Z

← Older revision		Revision as of 13:41, 26 April 2011
Line 1:		Line 1:
	This page applies when you use the Borland compiler to build BCI2000. It deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.		<!-- TODO: delete this page once the borland compiler is no longer supported. -->This page applies when you use the Borland compiler to build BCI2000. It deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.

	Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths); where this is not feasible, it tests for necessary conditions at compile time.		Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths); where this is not feasible, it tests for necessary conditions at compile time.

Mellinger at 13:41, 26 April 2011

2011-04-26T13:41:03Z

← Older revision		Revision as of 13:41, 26 April 2011
Line 1:		Line 1:
	~~<!--TODO: adapt to V3 -->~~This page deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.		This page applies when you use the Borland compiler to build BCI2000. It deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.

	Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths); where this is not feasible, it tests for necessary conditions at compile time.		Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths); where this is not feasible, it tests for necessary conditions at compile time.

Mellinger at 13:26, 26 April 2011

2011-04-26T13:26:35Z

← Older revision		Revision as of 13:26, 26 April 2011
Line 1:		Line 1:
	This page deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.		<!--TODO: adapt to V3 -->This page deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.

	Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths); where this is not feasible, it tests for necessary conditions at compile time.		Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths); where this is not feasible, it tests for necessary conditions at compile time.

Mellinger at 12:57, 19 August 2008

2008-08-19T12:57:08Z

← Older revision		Revision as of 12:57, 19 August 2008
Line 12:		Line 12:

	===PCH Policy in BCI2000===		===PCH Policy in BCI2000===
	The general BCI2000 policy regarding PCHs consists of ~~the following aspects~~:		The general BCI2000 policy regarding PCHs consists of three elements:
	*There is a specialized set of headers to include into PCHs, located at		*There is a specialized set of headers to include into PCHs, located at <br/><tt>BCI2000/shared/config/PCHIncludes</tt>, which contains a list of #includes.
	<tt>BCI2000/shared/config/PCHIncludes</tt>, which contains a list of #includes.
	*In each BCI2000 cpp file, the first lines of code are		*In each BCI2000 cpp file, the first lines of code are
	#include "PCHIncludes.h"		#include "PCHIncludes.h"
Line 22:		Line 21:
	**For online components, the PCH project setting is to use PCHs, with the cache file named above.		**For online components, the PCH project setting is to use PCHs, with the cache file named above.
	**For tools, PCH configuration should be set to "none".		**For tools, PCH configuration should be set to "none".
	The rationale for this is that experimenting with compiler settings makes less sense for online components than it does for tools, and online components make up most of the BCI2000 code. So the ratio of speedup to inconsistency trouble would be minimized that way.		:The rationale for this is that experimenting with compiler settings makes less sense for online components than it does for tools, and online components make up most of the BCI2000 code. So the ratio of speedup to inconsistency trouble would be minimized that way.

	== See also ==		== See also ==

Mellinger: /* Pre-Compiled Headers */

2008-08-19T12:54:46Z

Pre-Compiled Headers

← Older revision		Revision as of 12:54, 19 August 2008
Line 8:		Line 8:

	Unfortunately, PCHs may become invalid when compiler settings change, leading to the following situations when the same PCH cache is used by multiple project with differing header sets, or compiler settings:		Unfortunately, PCHs may become invalid when compiler settings change, leading to the following situations when the same PCH cache is used by multiple project with differing header sets, or compiler settings:
	#) Obsolete PCHs are detected correctly; as a consequence, PCHs are frequently recreated, resulting in slow builds.		#Obsolete PCHs are detected correctly; as a consequence, PCHs are frequently recreated, resulting in slow builds.
	#) Obsolete PCHs are not detected; as a consequence, linking or runtime errors may occur. Obviously, this is the worse situation, because the reason for the errors is quite difficult to understand.		#Obsolete PCHs are not detected; as a consequence, linking or runtime errors may occur. Obviously, this is the worse situation, because the reason for the errors is quite difficult to understand.

	===PCH Policy in BCI2000===		===PCH Policy in BCI2000===

Mellinger: /* Pre-Compiled Headers */

2008-08-19T12:54:36Z

Pre-Compiled Headers

← Older revision		Revision as of 12:54, 19 August 2008
Line 8:		Line 8:

	Unfortunately, PCHs may become invalid when compiler settings change, leading to the following situations when the same PCH cache is used by multiple project with differing header sets, or compiler settings:		Unfortunately, PCHs may become invalid when compiler settings change, leading to the following situations when the same PCH cache is used by multiple project with differing header sets, or compiler settings:
	1) Obsolete PCHs are detected correctly; as a consequence, PCHs are frequently recreated, resulting in slow builds.		#) Obsolete PCHs are detected correctly; as a consequence, PCHs are frequently recreated, resulting in slow builds.
	2) Obsolete PCHs are not detected; as a consequence, linking or runtime errors may occur. Obviously, this is the worse situation, because the reason for the errors is quite difficult to understand.		#) Obsolete PCHs are not detected; as a consequence, linking or runtime errors may occur. Obviously, this is the worse situation, because the reason for the errors is quite difficult to understand.

	===PCH Policy in BCI2000===		===PCH Policy in BCI2000===

Mellinger at 12:54, 19 August 2008

2008-08-19T12:54:15Z

← Older revision		Revision as of 12:54, 19 August 2008
Line 1:		Line 1:
	This page deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.		This page deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.

	Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths), or tests for necessary conditions at compile time.		Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths); where this is not feasible, it tests for necessary conditions at compile time.
	However, some aspects of compiler configuration need to be taken care of manually, and kept consistent across a number of project files.		However, some aspects of compiler configuration need to be taken care of manually, and kept consistent across a number of project files.

Mellinger at 18:39, 7 January 2008

2008-01-07T18:39:11Z

New page

This page deals with project settings, i.e. compiler/linker switches which are typically stored in IDE project files.

Generally, BCI2000 code tries to be portable, i.e. independent of machine type (little/big endian, byte lengths), or tests for necessary conditions at compile time.
However, some aspects of compiler configuration need to be taken care of manually, and kept consistent across a number of project files.

==Pre-Compiled Headers==
Most modern compilers offer a feature to store so-called "Pre-Compiled Headers (PCHs)". During the compilation process, parsing header files is responsible for a large amount of compiling time; at the same time, most source files include rather similar sets of header files. Thus, caching parsed headers offers a way to significantly speed up compiles and builds.

Unfortunately, PCHs may become invalid when compiler settings change, leading to the following situations when the same PCH cache is used by multiple project with differing header sets, or compiler settings:
1) Obsolete PCHs are detected correctly; as a consequence, PCHs are frequently recreated, resulting in slow builds.
2) Obsolete PCHs are not detected; as a consequence, linking or runtime errors may occur. Obviously, this is the worse situation, because the reason for the errors is quite difficult to understand.

===PCH Policy in BCI2000===
The general BCI2000 policy regarding PCHs consists of the following aspects:
*There is a specialized set of headers to include into PCHs, located at
<tt>BCI2000/shared/config/PCHIncludes</tt>, which contains a list of #includes.
*In each BCI2000 cpp file, the first lines of code are
#include "PCHIncludes.h"
#pragma hdrstop
:The first line includes the set of header files, and the #pragma tells the Borland compiler _not_ to add any further #includes to the set of PCHs.
*For BCI2000, the PCH cache itself is located at <tt>BCI2000/shared/obj/bci2000.csm</tt>.
**For online components, the PCH project setting is to use PCHs, with the cache file named above.
**For tools, PCH configuration should be set to "none".
The rationale for this is that experimenting with compiler settings makes less sense for online components than it does for tools, and online components make up most of the BCI2000 code. So the ratio of speedup to inconsistency trouble would be minimized that way.

== See also ==
[[Programming Reference:Cpp Coding Style]]

[[Category:Development]]