I really feel like the Code::Blocks project file has the concepts projects and targets confused. In other IDEs, targets would have names like "Windows Debug," "Linux Debug Unicode," "Windows Release," and "Windows Release Unicode." Projects would have names like "libcodeblocks," "codeblocks" (which would create the actual executable codeblocks.exe), "libwxscintilla," etc. Even though this is wrong in the project file, I'm really not expecting it to change. However, it makes it easier to describe what an attached property sheet is.
Having an application divided into its separate projects leads to a big problem. Code::Blocks doesn't support cross-project target-specific build properties.

These could be implemented in two ways: attached properties, or workspace properties. I'll describe what you would put in them, and then I'll explain the difference.
You would have global properties that apply to all build targets in one "property group". One of these would be defining "CB_PRECOMP". Another would be the "-g" compiler flag. Another property group would apply to all targets, but only for Code::Blocks plugins. One property in this group would be to link against "codeblocks" (libcodeblocks.a).
Property groups could be defined either in the .workspace file (workspace properties), or in an attached property sheet file, with an extension like ".props". The only advantage to workspace properties is no new files are in the project. Two huge advantages to linked properties are: 1) you could attach the property sheets to each project in the project's .cbp file, because the properties have more to do with a project than they have to do with a solution and 2) you could create a common property group and use it across completely unrelated projects, say all internal libraries for your company. I think attached properties are much more powerful and definitely the way to go.
The .props files could be stored in a new directory in the repository trunk/src/props.
You may or may not allow users to define properties in the .cbp files themselves. This action will be familiar to everyone, but conceptually discouraged. Inline formatting in HTML is allowed, but no questions asked CSS is a better way to format your pages. In the same way, attached property sheets are a better way of setting up your build properties. At the end of this post I've included a screenshot of the property manager for one of my Visual Studio 2005 solutions (eMule). As you can see, property sheets are attached to specific targets. I think a good idea would be to also allow users to attach property sheets to the project so they are applied to all targets for that project. VS2005 does not allow that (when you add a property sheet to a project, it automatically adds it to all of the projects targets). The second image shows how the heirarchal layout of property sheets allows for properties to be overridden.
Nothing will show this concept quite like a familiar example: property sheets for the Code::Blocks program.

I do not expect these to be complete, rather only complete enough to clearly show what I'm talking about.
----------------------------------------------
Property group: Global (GlobalProps.props)
Attached to: All Code::Blocks projects, non-target specific.
Include directories:
sdk\wxscintilla\include
sdk\as\include
sdk\propgrid\include
Linker include directories:
sdk\tinyxml
Compiler options:
-Wall
-g
-pipe
-mthreads
-fmessage-length=0
-fexceptions
-Winvalid-pch
Compiler defines:
CB_PRECOMP
----------------------------------------------
Property group: wxWidgets (wxWidgets.prop)
Attached to: All Code::Blocks projects that use wxWidgets, non-target specific.
Special note:
Could be included in the Code::Blocks distribution and be automatically attached with the wxWidgets template project.
Compiler include directories:
$(#WX.include)
$(#WX.lib)\gcc_dll\$(WX_PLATFORM)$(WX_SUFFIX)
$(#WX)\contrib\include
Linker include directories:
$(#WX.lib)\gcc_dll
Resource compiler include directories:
$(#WX.include)
Link libraries:
wx$(WX_PLATFORM)$(WX_VERSION)$(WX_SUFFIX)
----------------------------------------------
Property group: Windows (MsWindows.prop)
Attached to: All projects specific targets "Windows Debug", "Windows Release Unicode", etc. (All Windows targets).
Compiler defines:
HAVE_W32API_H
__WXMSW__
WXUSINGDLL
Global variables:
WX_PLATFORM=msw
WX_VERSION=26
WX_SUFFIX= (blank, will be overridden by the Unicode property group)
----------------------------------------------
Property group: Unicode (Unicode.prop)
Attached to: All projects, specific targets "Windows Debug Unicode", "Linux Release Unicode", etc. (all unicode-specific targets).
Special notes: Must be attached above (with higher priority than) MsWindows.prop or Linux.prop, so the WX_SUFFIX global variable is overridden.
Compiler defines:
wxUSE_UNICODE
Global variables:
WX_SUFFIX=u
----------------------------------------------
Property group: TinyXml (TinyXml.prop)
Attached to: The libtinyxml project, not target specific.
Compiler defines:
TIXML_USE_STL
[attachment deleted by admin]