Compatibility Information in CPS Files

It would be nice if my CPS files could describe how my library was built without be prescriptive to downstream consumers about how they should build.

For instance, it would be helpful to know that my library was built for C++20. It would not be helpful for my library to require all of its users to use a specific flag setting the C++ standard to 20. That goes in a build toolchain file, a build configuration file, or something of that nature.

I expect this information would be used to quickly ascertain incompatibilities across dependencies in clear ways that are not possible at the moment. In fact, it's is possible at the moment that a mismatching C++ standard, for instance, will compile and link fine but cause runtime issues in an production environment.

[mwoehlke]

It would not be helpful for my library to require all of its users to use a specific flag setting the C++ standard to 20.

I... don't think CPS does that? (Well, your package can do that, but that would be a case of "you shouldn't do that".) Language level is a feature, not a flag.

I'm also not sure what the use case is. Your library should specify the minimum language level required to compile against it. Anything else is informative, and therefore I don't know how we would normatively specify how to provide such information. (Suggestions?)

[bretbrownjr]

The use case is detecting when different libraries incorrectly disagree on relevant flags like -std, debug standard libraries, and other flags that require coherent application across all libraries that are linked together.

It's not generally possible for a built binary to be compatible for a range of standard versions, so we don't want to express that. We do want to be able to express that a given library was built with C++20 and its headers should likewise be parsed that way or run the risk of violating the One Definition Rule. Same goes for other flags like a -D flag set to be compatible with another library but this library otherwise doesn't provide or require.

[bretbrownjr]

I'm flexible on how to express these... I guess they're requirements, but in my mind they would inform compatibility checks to be performed by linters or build tools. Probably to start, I would add fields to my CPS files as an extension and then report back once I try some things out and come back with what I like.

But it's a legitimate use case if we want tools to tell us our libraries are behaving in ODR suspicious ways as a group. I think we do want that.

[mwoehlke]

The use case is detecting when different libraries incorrectly disagree on relevant flags like -std

Don't specify -std.

This is why we have features. We almost certainly need more features than are currently in the specification, but again, it's unclear why features aren't the solution here. I'm less convinced that I can't build my C++20 project against a C++11 library or vice versa, but if you want consumers to use (at least) C++20 to consume your library, declare the c++20 compile feature on yourself. Hopefully your tool will know if it can't satisfy that.

(The original intention is for standard library versions/flavors to be part of the platform definition. That, of course, is in flux, and we've also kicked around the idea of standard libraries being dependencies — your idea, IIRC. Again, an area that needs work, but in its current form, I'm not sure what this issue is adding to that conversation.)

[bretbrownjr]

I guess I am concerned that there is a large, unbounded, and nonportable set of compatibility modes to enumerate to avoid the ODR and compatibility bugs I'm concerned about.

Off the top of my head:

• architecture tuning flags
• standards versions
• standard language and library feature flags
• toolchain extension feature flags
• various incompatible parse modes for each standard library (i.e. ABI breaking debug modes)
• library specific feature flags, often of the form -DSOMELIB_USE_BOOST_OPTIONAL=1 and things like that

I don't expect to reasonably model all of that in CPS, especially things in that last category.

somelib.cps can and should, of course, specify that users should set SOMELIB_USE_BOOST_OPTIONAL. But if I include somelib headers, even in private implementation details, my users are incompatible if they for whatever reason aren't using that same setting and transitively pull in somelib. Again, it could be -freflection=c++2c, so don't get hung up on preprocessor definitions as such.

One solution is that everything that depends on somelib copies and repropagates these sorts of settings into their interfaces via their CPS files even if the relevant headers are not transitively exposed, but that doesn't seem like the right model to me, at least so far.