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).