General Format Description:

	Configuration directives can be passed either in a configuration file or
	through the command line using the -cfg option. The format for one directive
	is as follows:
		<directive> = <value>
	Whitespaces are ignored, except inside <value> (but trailing and leading
	spaces and tabs are stripped). If <directive> denotes a list of something,
	setting the value means appending to the list. There is no way of removing
	something from a list.
	There are several different types treated specially inside a configuration
	file. Following is a table of types and possible string representations of
	their value (does not contain types with simple conversions, i.e. strings
	or numbers, which are simply converted to their string representations):
	
	+------------------+--------------------------------------------------------+
	| Type             | String Representations for use with directives         |
	+------------------+--------------------------------------------------------+
	| bool             | "1", "yes", "on", "true" - "0", "no", "off", "false"   |
	| Color::ColorMode | "bright", "dark"                                       |
	| DefineMap        | <define> = <value>                                     |
	| LanguageType     | "c", "c++"                                             |
	| RuntimeType      | "dynamic", "static", "dynamic debug", "static debug"   |
	| SubsystemType    | "console", "windows", "windowsce", "wince", "posix"    |
	| ToolchainType    | "microsoft", "ms", "interixms", "gnu", "gcc"           |
	+------------------+--------------------------------------------------------+
	
	A configuration file itself can have the following format (does not apply to
	the -cfg option, which only takes single strings as desribed above):
	
		<directive1> = <value>
	
		section <sec1> {
			<directive2> = <value>
		}
		
		section default {
			<directive3> = <value>
		}
		
	The above example does the following: In any case, <directive1> is loaded. After
	that parity takes a look at the complete command line (this is done most likely
	before parsing the command line, if loading the default parity.conf). it searches
	for an argument matching a section name, for example -<sec1> (one dash, followed
	by the section name). So if one would define a section "posix" it can be enabled
	with "-posix". Be careful to not define sections that clash with other command
	line options! If parity finds such an option, it loads the section, in our example
	<sec1>, and thus executes <directive2>. The default section is executed if no
	other section switch is found on the command line. Be aware that no global
	directives are executed after a section definition, so those have to be positioned
	before the first section definition.
	
	Note: Sections are not currently supported by the graphical (and textual)
	      configurator (and they probably never will be supported). This is due
	      to the limited architecture of the configurators. The graphical
	      configurator however provides the capability of chosing which of the
	      sections available in a confg file to load in adition to the global
	      scope.
	
Configuration directives supported by parity:
=============================================	

DebugLevel (Level)
	Describes the verbosity of parity. There are four different levels available:
	 a) verbose: output internal diagnostic information
	 b) profile: output progiling information (time measurements)
	 c) warning: output warnings and errors (default)
	 d) error:   only output errors, no warnings.

BackendType (ToolchainType)
	Describes the type of Backend to use. This is used to decide which form
	of paths to use, wether command scripts are allowed, etc.
	Default: Microsoft
	
CtxDump (bool)
	Specifies wether the whole internal parity context should be dumped on
	the terminal. this is done using debug output with level verbose, so nothing
	will be written, if the debug level is less then verbose.
	Default: off
	
Colored (bool)
	Specifies wether the output should be colored. This not only colors paritys
	output, but also the output from the target compiler and linker.
	Default: on

ColorMode (Color::ColorMode)
	Can be either "bright" or "dark", describing the color type which should be
	used. Colors are chosen so that the output will be readable on the terminals
	background.
	Default: bright

GatherSystem (bool)
	Specifies wether system libraries should be taken into account when gathering
	symbol information. This does not bring any real advantage, except that system
	libraries can be preloaded with LD_PRELOAD. Be aware that this takes quite some
	time, even when linking one-liners.
	Default: off

GenerateLoader (bool)
	Specifies wether a custom loader should be generated. This makes features like
	LD_PRELOAD, hardcoded run-paths, lazy loading, etc.	possible. Without this
	directive enabled, all the above things will not be	available.
	Default: on
	
IgnoreForeignLibs (bool)
	Specifies wether parity should ignore libraries not built by himself. Such
	libraries, are not processed by parity, but rather given directly to the linker.
	This means that there will be nothing generated by parity for this library,
	no symbol table, no loader, etc.
	Default: on

LazyLoading (bool)
	Specifies wether lazy loading stubs should be generated. When GenerateLoader is
	enabled, parity generates stubs, that redirect to the real shared library symbols
	(only for functions of course). If Lazy loading is enabled at link time, those
	stubs get more complex, calling a routine from parity.loader, which knows how to
	load the corresponding symbol. This makes binaries a little larger, since symbol
	names have to be stored in the binary. This effectlively swaps loading times from
	startup- to run-time. However, the loader still does a LoadLibrary on every required
	library at startup time, since it has to load all data symbols. So Lazy loading only
	pays if there are very many functions to load from shared libraries, where possibly
	only a few of them are ever called during runtime.
	Note: There may be hard to find problems with lazy loading, if linking against an
	      external library, which may export symbols wrongly. For example if the external
	      library uses a .def file, but does not declare data symbols as DATA, the DLL
	      will export data symbols as functions. This works without lazy loading, since
	      all symbols are treated the same, but with lazy loading, data symbols have to
	      be loaded at startup, and code symbol loading can be delayed. If parity gets
	      to think a data symbol is a code symbol, it will load it in the wrong order,
	      which will cause random problem when accessing the data symbol.
	      This problem is undetectable, since parity initializes the import pointer
	      used to access those symbols to the address of a generated stub which does the
	      lazy loading. In the case of a function, this causes an additional function
	      to be called if the import is called for the first time. This function changes
	      the import pointer to the real symbol, effectively deactivating itself. If
	      the symbol is data, it still points to the stub, but accessing the symbol will
	      cause either an access violation, because the .text section is neither readable
	      nor writeable, or it will cause random values if reading/writing succeeds.
	Note: parity now ignores libraries not built by himself to avoid the above described
	      hard to find problems. Those libraries are linked just like without parity,
	      by passing them directly to the linker. This means that those libraries won't
	      be listed when inspecting binaries with parity.inspector. Also see the 
	      "IgnoreForeignLibs" directive.
	Note: Enabling lazy loading makes debugging in a shared library environment a little
	      harder, since the debugger no longer is able to "step into" over library boundaries.
	      This is because there is a bunch of code in between the two symbols in play,
	      for which there are no debug informations. This can be worked around, by
	      executing the "step into" from disassembly mode in developer studio. You will
	      end up inside a small stub function which is a few lines long. You can do a
	      "step over" at the "call" instruction you see there, until you get to the next
	      "jmp" which will take you to the real symbol. Once there, you can switch back
	      to source mode.
	      The problem does not affect breakpoints set into another shared library. Those
	      are hit as always.
	Default: off

ParityLoader (Path)
	Specifies a path to the parity.loader library to link every binary against.
	If no path is specified here, there is an internal lookup mechanism, searching for
	a version of this library in various places.
	Default: ""

PCRTLibrary (Path)
	Specifies a path to the parity.runtime library to link every binary against.
	If no path is specifier here, there is an internal lookup mechanism, searching for
	a version of this library in various places.
	Default: ""

PCRTInclude (Path)
	Specifies a path to the include directory of the parity.runtime directory, which
	is added to the command line of every compilation call. If no path is specifier here,
	there is an internal lookup mechanism, searching for a valid directory in various
	places.
	Default: ""

EntryPoint (std::string)
	Specifies the entry point function for the binary to be linked. If nothing is
	specified, the default entry points are used, depending on the target subsystem.
	Since parity generates chained entry points to initialize parity.loader and
	parity.runtime, this may not be the real entry point, but is called from another
	function after initializing other things.
	Default: ""

SharedEntryPoint (std::string)
	See EntryPoint. The only difference is, that SharedEntryPoint is used for shared
	libraries, and EntryPoint is used for executables. This distinction has to be done,
	since shared library entry points have a different signature.
	Default: ""

RunPaths (PathVector)
	Specifies a list of paths that are hardcoded into the binary when linking. These
	paths are used for the runtime shared library lookup mechanism of the parity.loader.
	If one or more paths are specified, the LD_RUN_PATH variable is ignored during
	linking.
	Default: (empty)

KeepTemporary (bool)
	Specifies wether temporary files should be kept, instead of deleting them at exit.
	parity creates zero to one temporary files per compilation, and up to approximately
	five temporary files per linker call, all of them in the current directory.
	Default: off

TimingShowTasks (bool)
	Specifies wether the Timing statistics shown with DebugLevel "profile" include timing
	information about every child process called by parity.
	Default: on

StatisticsFile (Path)
	Specifies the path to a file, where statistical information should be written to.
	Statistical information is only collected, if this file is set. After running parity,
	the file can be evaluated using the parity.statistics command line utility.
	Default: ""

IgnoreOutputFilters (bool)
	Specifies wether output filters should be ignored. There are various output filters
	set for the compiler and linker, stripping away warnings that don't make any sense
	when using parity, because they are either false positives, or save to ignore (for
	example a warning about optimization not beeing supported in the standard edition
	of cl.exe in Visual Studio .NET 2003).
	Default: off

AdditionalExecPaths (PathVector)
	Specifies a list of paths that are required to successfully execute compiler, linker
	and other utilities required by parity. These paths should be detected by the
	configure script of not using the win32 version of parity.
	Default: (empty)

GeneratePCRTEntry (bool)
	Specifies wether an entry point function for parity.runtime initialization should be
	generated. If this is disabled, parity.runtime will not be initialized. The binary
	which links against parity.runtime will still be fully functional, but some advanced
	features will not be available, like more Unixish exception handling (no message
	boxes, but rather a "core" file containing plain text exception information, including
	a stack trace), exception tracing, binary output streams (no \r on stderr, stdout and
	stdin), etc.
	Default: on

GenerateSymbols (bool)
	Specifies wether a Symbol Table should be generated while linking. This creates a
	table of symbol names, and relocations to the real address (so this effectively
	creates a reference to each and every local symbol, thus every object from every
	library on the link line will be linked in, even if it is otherwise unused). This
	symbol table can be used to get human readable stack traces from release binaries
	(for example when writing a "core" file).
	The default has recently been changed to off, since this can be enabled explicitly
	if searching for errors, and the dbghelp.dll library is not available.
	Default: off

UseCommandScripts (bool)
	Specifies wether command scripts should be used when starting child processes. This
	is done only if the utility which is to be started supports this. This way command
	line overflows can be prevented with very long command lines.
	Default: on

ExportAll (bool)
	Specifies wether all symbols should be exported, even from static libraries. This
	is enabled automatically by parity - if not already enabled, if it detects, that
	only static libraries are on the command line. By default parity does not export
	symbols from static libraries, since those are treated as private to each binary.
	Default: off

ExportFromExe (bool)
	Specifies wether parity should export all symbols from executables, much the same
	as when linking shared libraries. This has the advantage that dlopen() works on
	executables, and even the own process.
	The problem with this directive is pretty much the same as with GenerateSymbols:
	exporting a symbols results in a reference to that symbol. If one links against
	a static library containing (unneeded) object files, containing references to
	unavailable symbols (since the containing library is not on the link line), the
	link will fail, since those symbols are unresolved. Without this directive set,
	the link will go fine, since the linker finds the object inside the library
	unreferenced, and throws it away for this link.
	The default has been switched to off recently, since this is required only for
	special cases, where it can be turned on.
	Default: off

KeepComments (bool)
	Specifies wether to keep comments in preprocessed source files. Enabling this is
	the same as passing "-C" to the gcc compiler frontend on the command line.
	Default: off

NoStdIncludes (bool)
	Ignore the standard include directories when preprocessing. Be aware that enabling
	this results in no include paths beeing set except the ones provided by the user.
	Be carefull, when setting include paths yourself. For a list of standard system
	directories, see SysIncludePaths.
	
Defines (DefineMap)
	Specifies a list of key-value pairs, which describe defines set during compilation
	and preprocessing.
	Default: __PARITY__ (and depending on the frontend __PARITY_GNU__ or __PARITY_MS__)
	         Also the default parity.conf sets _WIN32_LEAN_AND_MEAN.
	         POSIX or MixedMode compiler modes set many others (see parity.conf).

IncludePaths (PathVector)
	Specifies a list of include paths. Specifying -I on the command line, results
	in the path beeing added to this list.
	Default: (empty)

SysIncludePaths (PathVector)
	Specifies a list of system relevant include paths. Paths cannot be added to this
	list from the command line.
	Default: a) the parity.runtime include directory, which overrides many include
	            files from the default c-runtime library.
	         b) the c-runtime library include directory from the compiler.
	         c) the Windows SDK include directory.

OptimizeLevel (long)
	Specifies the level of optimization applied at compile time. This can be a value
	in the range of zero to three. When building debugable code, be careful with
	optimization, since the debug information may no longer match the generated code.
	Default: 0

OmitFramePointer (bool)
	Specifies wether frame pointers should be omitted. If omitting those, the "ebp"
	register can be used as a general purpose register in addition to the existing
	ones. This makes it impossible to create stack traces for the current process.
	It even very likely crashes the program when trying to get a stack trace.
	Be aware that parity.runtime automatically creates stack traces on program
	crashes when GeneratePCRTEntry is enabled (which it is by default). This will
	most likely result in a nested exception, if not in a recursive exception, which
	crashes the program with false error messages, or simply leaves the process
	hanging.
	Default: off

InlineFunctions (bool)
	Specifies wether inline function expansion should occur. This is enabled by
	default with all optimization levels greater than zero.
	Default: off

UseSSE (bool)
	Specifies wether ther compiler should generate SSE instructions in the target
	object file, to speed up the resulting code.
	Default: off

UseSSE2 (bool)
	Same as UseSSE, except that this directive decides wether SSE2 instructions
	should be generated.
	Default: off

ForScope (bool)
	Specifies which scope variables should have, that are defined in the header
	of a for loop (C++ only).
	Default: on

MsExtensions (bool)
	Specifies wether Microsoft Extensions to C/C++ should be enabled.
	Default: on

WarningLevel (long)
	Specifies the warning level for the compiler. The higher the level, the more
	warnings get issued. The valid range is zero to four, where four produces
	extremely much noise on the terminal, which can contain false positives, and/or
	unwanted warnings.
	Default: 3
	
WarningAsError (bool)
	Specifies wether warnings should be treated as errors. This leads to compiler
	exit everytime a warning is encountered.
	Default: off
	
ExceptionHandling (bool)
	Specifies wether exception handling should be enabled. Internally in parity this
	results in /EHsc beeing put on the command line for cl.exe if the backend is the
	Microsoft compiler. However, without this option, exception handling is still
	enabled, but behaves slightly different.
	Default: on

RuntimeTypes (bool)
	Specifies wether Runtime Type Information (RTTI) should be generated, to enable
	C++ code to use things like "dynamic_cast".
	Default: on

ShortWchar (bool)
	Specifies wether the wchar_t type should be a sperate type or "unsigned short".
	Default: off

CompilerDefaults (std::string)
	Specifies the default arguments, that are passed to the compiler. This can be
	overridden, but be sure to include the existing default values for the compiler
	output and resulting binary code to remain compatible.
	Default: /nologo
	
AssemblerDefaults (std::string)
	Same as CompilerDefaults, but the arguments get passed to the Assembler.
	Default: /nologo /Cp

CompilerExe (Path)
	Specifies the path to the compiler to use, normally an absolute path to cl.exe.
	The default is an empty string, since a configuration directive is generated
	by configure into the default (installed) parity.conf.
	Default: ""

AssemblerExe (Path)
	Specifies the path to the assembler to use, normally an absolute path to ml.exe.
	The default is an empty string, since a configuration directive is generated
	by configure into the default (installed) parity.conf.
	Default: ""
	
TimeT32Bit (bool)
	Specifies wether the "time_t" type should be 32 or 64 bit wide. Be aware that
	changing this creates ABI incompatible code, and may break your or others
	libraries and/or executables.
	Default: on
	
Runtime (RuntimeType)
	Specifies which type of runtime to use when building and linking. Be aware that
	mixing this among libraries and executables can be dangerous, since the memory
	management functions are inside this runtime library. Allocating a pointer in
	one of them and freeing in another may result in errors.
	This can be	one of:
	 a) "dynamic"
	 b) "static"
	 c) "dynamic debug"
	 d) "static debug"
	Default: dynamic

ForcedLanguage (LanguageType)
	Specifies the language to use for any source file. Normally each source file has
	it's own source file type, which is determined through the file's extension.
	Using this directive (or the -x command line option, which sets this directive),
	one can force the compile, to - for example - compile everything as C++. This
	does not apply to assembler files, but only to C and C++. Possible values for
	this directive are:
	 a) "c"
	 b) "c++"
	Default: none

AnsiMode (bool)
	Specifies wether the compiler should run in an ANSI compatible mode. This is the
	same as disabling the MsExtensions directive.
	Default: off

StackReserve (long)
	Specifies the maximum size of the stack for each process. This is the hard limit;
	if the stack grows that big it will hit a "guard page". if this guard page is
	hit by a read or write operation, a stack overflow exception is issued.
	Default: 10485760 (10MB)

StackCommit (long)
	Specifies the initial size of the stack, before it starts growing. At the end of
	this stack is a guard page, which - when hit - generates an exception, which is
	caught by the system, which in response grows the stack. The stack size is limited
	by StackReserve; if the stack should grow bigger, the exception is passed through
	to the application (which usually results in termination).
	Default: 65536 (64KB)

HeapReserve (long)
	Specifies the maximum size of the Head in virtual memory. This settings seems to
	be ignored by the linker, since every process can allocate until memory runs low.
	Default: 10485760 (10MB)

HeapCommit (long)
	Specifies the commit value for the process Heap, which is subject to interpretation
	by the operating system. Usually this specifies the minimum size of each allocation
	on the heap. Since memory management is done by the C runtime library, this does
	not mean that every call to malloca allocates such a piece of memeory, but rather
	that the C runtime library gets such chuncks which it in turn can split into smaller
	pieces passed to the application. Specifying a higher value here, can increase the
	(initial) memory requirements for an application, but in turn saves time when the
	application needs more memory.
	Default: 65536 (64KB)

LibraryPaths (PathVector)
	Specifies a list of paths used during library search. Since the library search is
	done in place, as soon as a library argument is encountered in either the config
	file or the command line, the matching LibraryPaths have to be set before adding
	the libraries.
	Default: (empty)

LinkerSharedDefaults (std::string)
	Specifies the default arguments passed to the linker, when linking shared libraries.
	When overriding be sure that you pass in the original default value too, since this
	is required for purify cleanlyness.
	Default: /nologo /incremental:no

LinkerDefaults (std::string)
	Specifies the default argument passed to the linker, when linking executables. This
	is the same as LinkerSharedDefaults otherwise.
	Default: /nologo /incremental:no /fixed:no

LinkerExe (Path)
	Specifies the path to the linker to use, normally an absolute path to link.exe.
	The default is an empty string, since a configuration directive is generated
	by configure into the default (installed) parity.conf.
	Default: ""

SysLibraryPaths (PathVector)
	Specifies the system library paths. This is usually done in the default parity.conf,
	where the paths are collected by configure.
	Default: (empty)

ObjectsLibraries (PathVector)
	Specifies the list of objects and libraries which are to be linked together. This can
	be extended with this configuration directive, or by passing files on the command line.
	Most required libraries to link even more complex applications are added to parity.conf
	by configure at compile time.
	Default: (empty)

ForceLink (bool)
	Specifies wether the link should be forced to run through even if there are duplicate
	or missing symbols. Unresolved symbols will cause an abort at runtime, as soon as the
	symbol is accessed or called. Duplicate symbols will result in the first seen instance
	to be used.
	Default: off

Subsystem (SubsystemType)
	Specifies the subsystem to link for. Depending on this value, the default entry point
	for binaries is calculated by parity. The only other impact is, that the resulting
	binary has the subsystem type set in the PE/COFF headers, and that different default
	entry points may require different user supplied entry points (for example main for
	the CONSOLE subsystem and WinMain for the WINDOWS subsystem). Possible values are:
	 a) "console"   - the default console subsystem
	 b) "windows"   - the windows subsystem
	 c) "windowsce" - the windows ce (windows mobile) subsystem
	 d) "posix"     - the posix subsystem (i.e. SFU/SUA).
	Default: console

ManifestExe (Path)
	Specifies the path to the manifest tool, which is required to embed manifests into
	binaries. If this is not done, the manifest needs to be copied along with the binary
	for it to be executable. The manifest tool usually comes with the Windows SDK.
	Default: ""

ManifestDefaults (std::string)
	Specifies the default command line arguments passed to the manifest tool.
	Default: -nologo

DefaultOutput (Path)
	Specifies the default output name. Be aware that this name is also valid for shared
	libraries, which can result in misleading binary names!
	Default: a.exe

DefaultConfigSection (std::string)
	Specifies the name of the default section, which is the section that is loaded if
	no other section is specified explicitly on the command line.
	Default: default