User forums > General (but related to Code::Blocks)

Purpose of projects

(1/2) > >>

spoofer:
Projects in Code::Blocks are used quite differently then in other IDE (AFAIK). Here projects are used for nothing more then to tell where to place object/dependency files, while targets are used to tell which options to use when compiling and linking. Note this: you specify executable name for projects, but linking flags for target. Which means that each projects needs it's targets (no target reusing). Personally I find this way to be much better:

Options used for build =
  global
+ project specific   (source files, minimal compiling and linking flags)
+ target specific    (optimization, debugging ...)

For example, this way Code::Blocks source would have projects for tinyXML, wxDoctIt, SDK, while targets would be Release, Debug, Profile.

thomas:
Hmm... actually you don't specify an executable name per project, but per target.

I find the way Code::Blocks handles things a lot easier than for example how Visual Studio does (I assume you did not mean to compare to Dev-CPP or Relo which are rather poor at handling projects).

On a large project, you would have one workspace and 20 project files using Visual Studio. One project file for every library, part, or executable that you want to build, with optional inter-project dependencies.

Code::Blocks uses one project file for everything and just defines one target for every component, this is a lot simpler and easier to follow. All dependencies are in one file, too.

You can very well work like this to get to your debug/release builds:

A workspace is just a convenient collection of projects.
A project holds together everything that makes "one product" or "one product suite". Change the optimization/debug flags here, all targets will inherit them (unless they explicitely override them). This is for example important if you use "dangerous" tuning parameters like regparm which generate non-ABI compatible code. With the VS approach, your code would crash and burn.
A target defines every "entity" which may be built separately. This may be a shared library, a static library, a plugin, a tool, or two different versions of the main program (a full version and crippleware version, for example).

It is different from how MS does it, true, but is it worse? A matter of taste I'd say :)

takeshimiya:
Mm, yes, it's a matter of taste, it would depend on what you're used.

For version post-1.0 (compiler revamping), I would suggest a poll in this case

hcye:
Is it possible to associate a file only to a target?

For example, I have many small files each with its own main() --- they are not part of the project but for unit tests only. I have been doing this in a pretty dumb way --- whenever I need to run a test, I add the file to project, and when it's done I remove it. It would be great if I can create a target for each test, and associate a test file with it, without causing multiple main() conflict.

Is there a way to do this? Thanks in advance!

mandrav:
In project properties, where you setup the targets, there's a list of the files inside the project with a checkbox next to each. Each checked file belongs to the target.
So, yes you can do it.

Navigation

[0] Message Index

[#] Next page