Author Topic: "Targets" v. "Projects" and (attached|workspace) property sheets  (Read 24833 times)

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
"Targets" v. "Projects" and (attached|workspace) property sheets
« on: December 29, 2005, 06:41:20 pm »
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]
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #1 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...
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #2 on: December 29, 2005, 07:07:12 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...

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

This has absolutely nothing to do with inter-project dependencies.
« Last Edit: December 29, 2005, 07:15:12 pm by 280Z28 »
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #3 on: December 29, 2005, 09:15:31 pm »
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.

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.
Be patient!
This bug will be fixed soon...

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #4 on: December 29, 2005, 10:01:57 pm »
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.
« Last Edit: December 29, 2005, 10:06:46 pm by 280Z28 »
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #5 on: December 29, 2005, 10:15:34 pm »
Visual Studio has this thing where C code is colored for keywords and comments. They call it "syntax highlighting." I've attached a screenshot.

Visual Studio has this feature, and I want Code::Blocks to have it too. Therefore, I want Code::Blocks to be Visual Studio??  :?

My original post developed concepts in a logical manner, was not aggressive. I gave pros and cons I've experienced with things, and gave visual and textual examples of how things could proceed. I did not set a timeline for this, and I did not post in the forum for SVN head discussions. In fact, in my timeline thread earlier I stated attachable property sheets as something I want to see in 2.0, not earlier. You two need to step back for a minute and re-read my posts. Stop assuming I'm attacking you and/or saying bad things about your project.

You should know by now I want to see C::B become a great editor. Please try to treat me and my posts as someone also trying to achieve that goal. If you are looking for someone who just likes to complain, I'm sure I can find other posts on this forum from people who like to do so.

[attachment deleted by admin]
« Last Edit: December 29, 2005, 10:20:25 pm by 280Z28 »
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #6 on: December 29, 2005, 10:35:43 pm »
Visual Studio has this thing where C code is colored for keywords and comments. They call it "syntax highlighting." I've attached a screenshot.

Visual Studio has this feature, and I want Code::Blocks to have it too. Therefore, I want Code::Blocks to be Visual Studio??  :?

Now, who's being sarcastic here?  :?

You two need to step back for a minute and re-read my posts. Stop assuming I'm attacking you and/or saying bad things about your project.

No, you need to step back and re-read our posts. No one is attacking you. I just explained to you that the difference between targets and configurations is conceptual only. I also told you to wait for the compiler redesign.
Where 's the attack in these?!?

And if you 've taken my comment on cloning VisualStudio as an attack, then what can I say? When you 're talking about creating ".props" to replicate ".vsprops" am I wrong in deducing you want to make C::B behave exactly like VS?

You should really calm down. Not everyone is against you and not everyone is attacking you...  :roll: :|
Be patient!
This bug will be fixed soon...

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #7 on: December 29, 2005, 10:48:26 pm »
You said I was being confused. But I was talking about a project file, not people. Instead, you could have said "The project file is done that way for _____ reason" and left comments about me out of it. ".props" could be anything, but it is a properties file and that's what made sense. This isn't about Visual Studio so much as it's about a concept. I just had VS there for a handy screenshot of such a feature in action.

I don't want it to behave exactly like VS. Among other things, I don't like how VS doesn't allow you to have a property sheet apply to a project as opposed to just individual targets.

You said "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." I would have been less aggrivated by something like this:

"We've been thinking about a compiler framework design sometime after 1.0. Property sheets are an interesting idea that might be included at that time, we'll have to see."
« Last Edit: December 29, 2005, 10:55:23 pm by 280Z28 »
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #8 on: December 29, 2005, 10:54:49 pm »
The policy combo boxes are especially good if you want to apply properties to most but not all targets, but don't offer something like "Append/Prepend the options to ones from xxx target in another project." That would actually accomplish the feature set I want. It'd be a somewhat clumsy solution, but with the bit of a learning curve covered it would be sufficient until something better came along.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #9 on: December 29, 2005, 11:31:44 pm »
I just deleted a long post I wrote to answer. You know why? It's not worth it.
I 'm not gonna argue with you. I have more important things to do than having a dispute through the internet.
Feel free to think that I attacked you. I didn't but hey, what you think is more important to you. You 're entitled to your opinion, as I am to mine.

Over and out.
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #10 on: December 29, 2005, 11:39:46 pm »
Wooooops, who turned the heat on in here.

Seems like "targets vs projects" could be an endless discussion (well Yiannis and I had a minor one on that issue to). It's as Yiannis says, you (nearly) can have it several ways, so that's good.
What we do need though (IIMHO) : some examples in the wiki where we show the possibilities of those different ways of doing it, since we all want CB to rock hard, and then it will get new users coming from the Visual Studio audience. I also use VS a lot, but I prefer to work in CB, I miss things in CB, but I am willing to wait for them to arrive ;-)
No no, no copy of VS to be CB, only take the good parts and doing it better. So we have to show those users how the ncan work the VS way, and the alternative ways.

A suggestion I would like to make is can't we create 1 post (yes just 1), where 1 moderator manages the first post and can optionally remove the reply posts, hmm, now what could that post be :
"(future) Feature ideas for the next version(s) of CB". So everyone can reply with an idea, no discussion of the idea (linkt to another topic in the forum for that), and the moderator maintaines the list of those ideas in the first post.
So it's far from a roadmap, but it's some sort of wishlist.
What's the benefit of this : 1 place to look for alread mentioned ideas (search the forum might be troublesome).
Note : the words "future versions", might be 1.1, 2.0, or even the next headrevision.

What do you think ?

I have tried the same for the community patches, but that one is not catching on yet, just entries from some dude killerbot  8)

There's no doubt that together we will lift this project on a higher level, stop and think : we already do this, every day again and again.


Cheer,
Lieven

PS : still looking forward to the first big CB convention for developers and users .... dream dream dream .... sigh ....



EDIT : Yiannis just also posted a reply at the same time : we better stick to the over and out.
« Last Edit: December 29, 2005, 11:41:42 pm by killerbot »

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #11 on: December 29, 2005, 11:50:16 pm »
I just deleted a long post I wrote to answer. You know why? It's not worth it.
I 'm not gonna argue with you. I have more important things to do than having a dispute through the internet.
Feel free to think that I attacked you. I didn't but hey, what you think is more important to you. You 're entitled to your opinion, as I am to mine.

Over and out.

I actually want to know what you think of the idea of attachable properties as a whole. Even if we don't use them for the Code::Blocks project file, do you think support for them should eventually be added?

What about a modification (addition) to the policy combobox? How do-able is an idea like that?
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #12 on: December 30, 2005, 12:10:06 am »
@mandrav: From here on out, I'm going to interpret your posts with the assumption that you don't make posts to attack me (but you can disagree with my ideas, that is absolutely fine). You reply with a different style than I do, but we're good now since you have clearly stated that you aren't attacking me. On that issue, I won't bring it up again.  8)

@thomas: Are you in on this as well? Just say the word and I'll do the same for you. :)
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #13 on: December 30, 2005, 12:19:11 am »
280: I have a better idea. It's WAY TOO LATE to modify the compiler framework by now. But I've noticed your (sometimes overzealous :P ) excitement and desires to improve it.

Fear not: You're invited to collaborate on the COMPILER FRAMEWORK REDESIGN! :D

Thomas and I came up with the idea today. If we start now, we might be able to have it completed by next June.

The idea starts with this: A cbVariant class. It will hold either a bool, an int, a char, a float, or a wxString. Comparison and assignation will be done through operator overloading. A special InvalidVariant object will be used for invalid values.

The idea further expands with a map<wxString, cbVariant, less<wxString> >. This is also known as an associative array.

My goal is to make a "universal" (recursive) configuration object that will be able to serialize all of its properties. What do you think? I'll create a new forum for the whole redesign issue.

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: "Targets" v. "Projects" and (attached|workspace) property sheets
« Reply #14 on: December 30, 2005, 12:25:17 am »
The idea further expands with a map<wxString, cbVariant, less<wxString> >. This is also known as an associative array.

Sorry rick for the remark, but it would not be better to use a generic comparator instead of less? I mean, if you would like to change later and using, e.g., greater<wxString>, then it would be easier to do.

Michael
« Last Edit: December 30, 2005, 04:07:52 pm by Michael »