[CCpp]: Is it justified to have a separate target, rather than just a flag?

[Soroosh129]

Originally from @lhstrh here.

The CCpp target itself still doesn't make sense to me. I think a target should specify a language, not a build configuration.

The CCpp target was created to facilitate the use of C++ code and libraries in the C target. The core reason why we initially went with a target rather than a flag was, as the documentation puts it, because

[an] .lf file that uses the CCpp target cannot and should not be imported to a .lf file that uses the C target. Although these two targets use essentially the same runtime, such a scenario can cause unintended compile errors.

[lhstrh]

While I agree with the cited documentation, I don't see why this would justify reserving a target for it. It can be easily checked whether a file is suitable for import by looking at its target properties rather than just its target.

There will also be other combinations of target properties that are incompatible (e.g., think of files that require specific platform support, such as Arduino).

In my mind, reserving a target is justified if (and only if):

• it denotes an actual programming language;
• has its own runtime associated with it;
• has its own suite of regression tests; and
• has its own documentation on the website.

For CCpp, none of these things are true.

[cmnrd]

There will also be other combinations of target properties that are incompatible (e.g., think of files that require specific platform support, such as Arduino).

I agree. In fact we already have several properties that can cause problems when combining them. (e.g., build, build-type, cmake, cmake-include just to name a few).

Looking at this from a completely different angle: I think that CCpp is an ambiguous name and it is confusing that there is a CCpp target and a Cpp target. Having a C target that also supports embedding C++ code seems a lot clearer to me.