Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

"Targets" v. "Projects" and (attached|workspace) property sheets

(1/5) > >>

280Z28:
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]

thomas:
Sam, all of this has been thoroughly discussed in the past.

Apart from that, your information is incorrect. Revision 1499 implements inter-project dependencies...

280Z28:

--- Quote from: thomas on December 29, 2005, 07:04:36 pm ---Sam, all of this has been thoroughly discussed in the past.

Apart from that, your information is incorrect. Revision 1499 implements inter-project dependencies...

--- End quote ---

I searched but I can't find anything about it. :(

This has absolutely nothing to do with inter-project dependencies.

mandrav:
Sam,
we are not trying to rewrite VisualStudio here. You 're a bit confused because you seem to want to turn C::B into VS.


--- Quote ---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.
--- End quote ---

No mate, you 're the one being confused and I can't blame you if you 've only used VS until now.
First, "other IDEs" don't do this. Only "one specific other IDE" does.
Second, in C::B targets are what you want them to be. You want them to be like VS configurations. Fine. I on the other hand want them to be targets, in the unix makefiles way. That's fine too. They both do the same thing, but differ in terminology.
If you look more carefully at what C::B allows you to do, you will see you can replicate most of what you write above. It might take a little longer to setup but that's the price for the freedom you get. For example, have you ever noticed the "Policy" combo-boxes in the various tabs of the project's build options?

Finally, you surely can't expect this to change any time soon, do you? This discussion will be more appropriate when the time comes for the compiler framework redesign.

280Z28:
Yeah I wasn't expecting any of this before 2.0 work.

The only new feature here is a way of applying sets properties to multiple projects, with an example of an easy way to do so.

Edit: I am not confused in the slightest. :)

If I wanted Code::Blocks to be Visual Studio, I'd just use my full licensed copy of Visual Studio 2005 Professional.

Navigation

[0] Message Index

[#] Next page