advanced use of project files

[killerbot]

At a given moment the wizards no longer suit your needs or slow you down. At such time one manually manipulates/copies/... the .cbp file.
There are however a few issues to encounter or other welcome enhancements.

I will address every now and then one in this topic.

1) static library with different targets, where each target is a different compiler or Debug/Release variant
* several target libraries will be created, all according to a similar structure and all for similar targets. THere will be different compilers, and each has a Debug/Release variant.
Let's assume here we have 2 GCC based compilers : our PC system compiler and a cross compiler.

This means :
- all compiler settings (defines, warning levels, etc ..) can be shared between the targets ==> specified at project level
- some settings are different per target ==> specified at target level
- output name of the library is the same per target but needs to end up in a different location
      + library name : libXXX.a ==> XXX is the name of the library, and in our use case the name of the project
      + location can be based upon the target name
- the same files (units) aply to all targets (and if needed can be specific)
- include paths apply to all targets ==> specified at project level

Below is an example of such a setup (some stuff left out to focus on the issue at hand):

Code

	<Project>
		<Option title="Parser" />
		<Option pch_mode="0" />
		<Option compiler="gcc" />
		<Build>
			<Target title="GnuDebug">
				<Option output="../Deliv/$TARGET_NAME/${PROJECT_NAME}" prefix_auto="1" extension_auto="1" />
				<Option working_dir="" />
				<Option object_output="../Deliv/$TARGET_NAME" />
				<Option type="2" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-g" />
				</Compiler>
			</Target>
			<Target title="GnuRelease">
				<Option output="../Deliv/$TARGET_NAME/${PROJECT_NAME}" prefix_auto="1" extension_auto="1" />
				<Option working_dir="" />
				<Option object_output="../Deliv/$TARGET_NAME" />
				<Option type="2" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-O2" />
				</Compiler>
			</Target>
			<Target title="CrossCompilerDebug">
				<Option output="../Deliv/$TARGET_NAME/${PROJECT_NAME}" prefix_auto="1" extension_auto="1" />
				<Option working_dir="" />
				<Option object_output="../Deliv/$TARGET_NAME" />
				<Option type="2" />
				<Option compiler="powerpclinuxgnultib" />
				<Compiler>
					<Add option="-g" />
				</Compiler>
			</Target>
			<Target title="CrossCompilerRelease">
				<Option output="../Deliv/$TARGET_NAME/${PROJECT_NAME}" prefix_auto="1" extension_auto="1" />
				<Option working_dir="" />
				<Option object_output="../Deliv/$TARGET_NAME" />
				<Option type="2" />
				<Option compiler="powerpclinuxgnultib" />
				<Compiler>
					<Add option="-O2" />
				</Compiler>
			</Target>
		</Build>

As can be seen, this is easy to maintain and reuse as a template. All one need to do is kick out the include paths and units of the previous project and fill in the new ones (adding files through the gui ;-)  ), change the project name and specify the new include paths (manually or though the gui).

Now we know the use case, let's focus on a first BUG :

Code

				<Option output="../Deliv/$TARGET_NAME/${PROJECT_NAME}" prefix_auto="1" extension_auto="1" />

This will deliver us (focusing on linux ) a new library : ../Deliv/GnuDebug/libParser.a. Note how the lib prefix and file extension get added, just as we specified.

The moment we change some project/target setting (could be we don't even need to change anything, just have build options show in the gui and click ok) and then 'save project' : the project file contains another unwanted change :

Code

				<Option output="../Deliv/$TARGET_NAME/lib${PROJECT_NAME}" prefix_auto="1" extension_auto="1" />

Yes, the "lib" prefix shows up in the project file. The good thing we won't end up with a liblibParser.a CB is smart enough :-)
However that lib should not end up in the project file, because when moving to another OS, this might not be the correct prefix (if any). It was the whole point to have it auto prefixed. Note that the extension nicely does not show up in the project file.

Any other ideas/comments on this bug ?

PS : another use/case issue will follow after this one has been addressed.