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

Scripted wizards

<< < (6/6)

killerbot:
just a shorty :

To be honest, one needs debug and release builds, for the simple reason that the final product should be a release build (== optimized), but then you can't debug, so you also need a debug build. Maybe think of it as debug/release configuration. So templates that setup these kind of configurations are good. And I am not just talking pc application, this also applies for embedded application, there (even more) you want optimized builds.

I think the example raised somewhere above of a project file with 3 targets:
 - component
 - test code
 - the app,
is not so nice in terms of I reusage of projects. I want people to reuse my component, and together with the source I provide them with a project file to build it (so they don't need to worry about defines, and other settings), but in that distribution my testcode and my app should be out. Well my component could be used in many apps (again think for example tinyxml) so why would "my"app by "the" app, far from it. From that point o view I provide debug build(configuration) (for people who like to debug it, in case they think there might be a problem on the inside), and the normal (preferred) usage would be the release configuration. And for dependent projects you can have a chain of debug's and a chain of release's. It's a nice "near"-standard. otherwise chaining for dependency will be less straight forward.

I don't say the other approach is not good, it is, otherwise we wouldn't have this exchange of ideas, but I feel it's not the best default. For sure in the pc world and definetely in the embedded world, debug/release configurations is what you need. Development and later on bugfixing requires the debug configuration, and the performance of the product requires the optimized (release) build (for example on a ti dsp, it's in speed 2 to 3 times faster in optimized build compared to debug build).

tiwag:
@killerbot
i second every word regarding the need for Debug- and Release- (and even other test-) builds.

but for the last time i want to say, that it is much less effort, if you organize them as projects
(Debug-Project, Release-Ansi-Project, Release-Optimized-Speed-Project, ...) instead as targets in each project.

building of the whole app is much more easy, and Creation of a new Build can simply be done by
copying the project file to  a new name and edit the project-wide settings
(with the Debug/Release/...-Targets approach you have to edit every single projectfile)

edit:
brgds, tiwag

killerbot:

--- Quote ---but for the last time i want to say, that it is much less effort, if you organize them as projects
(Debug-Project, Release-Ansi-Project, Release-Optimized-Speed-Project, ...) instead as targets in each project.
--- End quote ---

little drawback : add a new file to the project --> modifying 3 projects, otherwise 1, and disritbuting severl project files instead of 1

Main thing : CB allows both, so we can have wizards for both kind of flavours, we just need to well document them, simple huh ... ;-)

thomas:
I think tiwag is right in most of what he said, even though I am of course aware that it is in vain anyway.

MortenMacFly:
I'd like to give an example where this does not apply:
At work we have several cross-platform applications (processes) that communicate with each other (via IPC) on different hardware platforms.
Thus all of these applications have it's own project, some of them share source files. Now each of these projects has several targets: Release and Debug; for Windows/Linux/QNX and another two for hardware-in-the-loop and software-in-the-loop simulations. This makes sense because the targets differ in the compiler (all compilers work on Windows but produce platform code), in the type of library to link against (platform, release, debug...) and in the defines applied for compilation.
As we have 2 major target platforms that have different hardware (one has less than the other), Thus we have 2 workspaces that include the projects (applications) for this specific platform. Virtual targets control the overall build process - thus, is it debug/release, do we want to build all applications in the workspace for one platform only (e.g. QNX) etc.
Now maybe I fail to understand but I believe that this is a good concept of project management for *our* case - at least it has proven to work very well. Maybe someone can tell me how to do this project- and not target-wise...?!

In the end: I think it is *very* good, that C::B supports both philisophies as I see that both have their pros and cons depending on what you are developing. For me the release/debug starting point is very good, because then I can just copy a target and adjust the parameters (defines, libs) for another platform but still have only one project per application running on all targets.

I have started to work on a concept for a "target wizard" though but I'd like to ask another question: Are you aware that currently it is possible to create an empty project using a wizard and then add only targets (that can be fully specified) to this project using another wizard? Would it be helpful to have a wizard that combines both to a single wizard?

Ps.: tiwag: In the end I don't like if someone calls others an i****t. I really try to think before I decide on how to setup projects and again: This setup have proven to work very well. We shouldn't come to a level here were we shout at each other.

Navigation

[0] Message Index

[*] Previous page