Target All : new feature idea

[killerbot]

In the cbp file, for every unit, it is specified to which target it belongs. When you don't do anything special, this is most probably the 'default' target.

Now suppose you have the following, you have created library, which consists out of platform (and even compiler) independent code. And you want to compile it with a whole bunch of compilers, why ?
More compilers -> more robust for warnings, errors
Different platforms -> other compilers.

So you either GUI yourself through project settings, with copying one target to another, and then just change the things needed, or you do the copy/paste in the cbp xml file itself (way faster ;-) ).

But what if I could write this :
      <Unit filename="MyFantasticCode.cpp">
         <Option compilerVar="CPP"/>
         <Option target="all"/>
      </Unit>

Introducing a special target, the "all" target, that means, that every target that is specified in this cbp file, it belongs to it. For sure, there are lot of situations, where this does not apply, for example I don't want my source file to be in CB target, sdk target, or for that matter in the code completion plug-in target (it might slow it down ;-) ).

But in the usage I started this topic out with, it's for sure very usefull.

I have some ideas on how to implement it, off course this depends on the fact that units come after the targets in the cbp file (and are processed in this manner), so they can be added to the target specified (so in code that target already has to exist, so nothing new here).

So what do you think : praise ? horror ? great ? shoot it down ? superb ? where's that needle ? ....


Cheers,
Lieven

[jc]

This is pretty easy to do with projects; wouldn't "duplicate project, change compiler" be a nice way to do this? (Recreating the project by hand is not so fun.)

This necessitates using .workspace files as opposed to .cbp, but I think that's how this would work, conceptually. You'd still need alternate output directories to keep things from getting mixed up.

A duplicate project feature should be trivial to implement. Wonder if anyone else would go for it? Is it a crazy idea? I may not be thinking this through enough. But either way, I use the VC++ Toolkit 2003 alongside GCC/MinGW 3.4, it would be nice to have this feature, I just don't see how it would work in practice other than how I currently do it.

[killerbot]

yes, you are correct,that was another idea I had, maybe not always .objs, but something derived from the targetname. But need to think more about this one first.

[takeshimiya]

Just an idea: Shared targets, or Shared-option targets.

[duncanka]

A duplicate project feature should be trivial to implement. Wonder if anyone else would go for it? Is it a crazy idea? I may not be thinking this through enough. But either way, I use the VC++ Toolkit 2003 alongside GCC/MinGW 3.4, it would be nice to have this feature, I just don't see how it would work in practice other than how I currently do it.

How would this differ from just hitting "File-->Save project as..."?

Just an idea: Shared targets, or Shared-option targets.

It seems to me that "shared-option targets" would be just as easy to specify simply by allowing multiple-selection on the build options dialog, allowing the user to set multiple targets' options simultaneously.
But what do you mean by "shared targets?"  What would be shared between what?

[jc]

How would this differ from just hitting "File-->Save project as..."?

Different dependencies, different output directories. Release/Release-mingw, etc. A duplicate option would basically change the defaults to something you specify. But you're right, "save project as" brings you like 90% there.