Justification for Compiler and Linker Features

[bretbrownjr]

Scope

I'd like to kick off a thread discussing the Compiler and Linker Features section of the specification, mostly because I'm not sure what to do with it.

I'd like to hear the motivating use cases for these features. There are other alternatives to approaching those outcomes, including not worrying about relevant use cases yet, and I'd like to make sure I understand why this approach was used.

Note that most modern build and packaging systems have some notion of "profiles" or "toolchain specifications" that sort of serve the same purpose. I was expecting the ecosystem would want to converge on some commonalities in those problems, but I was expecting we could circle back to that later, or perhaps even in a different specification.

Completion Criteria

Any of these should be fine:

• Developer documentation to clarify the motivation for the use cases, perhaps just linking to this discussion from wiki pages if nothing else
• A new enhancement issue to circle back on this later
  • ...and a pull request to remove the Compiler and Linker Features page, at least temporarily

[dcbaker]

the case of having various language supported standards is one that seems quite common. Being able to document the language standard(s) you support as a dependency is a common problem for complex dependency trees, especially when you have a different ABI than implementation language. I have a few examples:

• a project compiled in C++14, but that also exposes a C99+ compatible API (can't remember which project this was)
• A project that supports using gnu99 or c99 as a fallback, but with worse performance (glib)
• A project implemented in Rust that exposes a C ABI

[bretbrownjr]

Why not implement in terms of CPS files describing the libraries or interfaces in question?

[mwoehlke]

Why not implement in terms of CPS files describing the libraries or interfaces in question?

That is somewhat on the table, but how do you express what language standard level you want when the same .so services the standard library for whatever level you request? Also, how does the build tool know about these hypothetical libraries/interfaces?

Note that this is related to #32.

(Also, the historic answer is "because that's how CMake works".)

[dcbaker]

how do you request that you want a different standard though? This is important because in C you are (except in rare cases) safe to use a newer standard, but that's not always true in C++, as things are sometimes removed (auto_ptr) or repurposed (auto).

My problem might actually be beyond the scope of this issue, but it's something that has been a huge pain for Meson with glib since there isn't a good way to model this in either Meson or in pkg-config

[bretbrownjr]

That is somewhat on the table, but how do you express what language standard level you want when the same .so services the standard library for whatever level you request?

Same way you support any flavor of any library? I'm not convinced there's anything special about the standard library in this regard.

To rephrase, why wouldn't the standard library provide a series of configurations for these sorts of variations? The configurations could be basically empty names in a lot of cases.

If that seems like a lot of combinatoric configurations (it is), we should keep in mind that popular library collections like boost would have approximately the same support surface area. In fact, it could be slightly worse for higher level libraries because they start accumulating API and ABI important options from their transitive dependencies as well. This is why I'm a little skeptical that we can describe configurations as strings like "Debug" and "Release".

It almost seems cleaner to not model all of this with as much detail and instead provide ways to fail gracefully as appropriate. For instance, if a package requires exactly a specific C++ standard version (see: anything like boost and abseil that optionally backport C++ standard library features), it could declare it only supports a specific C++ version. The end user could override, but by default there would be a cleaner error message describing the cause of the mismatch and links to troubleshooting guides.

I've briefly mentioned it before, but it's possible that we're overdue to just model "baseline build consistency requirements" as orthogonal to dependency resolution for the most part, similar to:

• CMake Toolchain files
• Conan profiles
• vcpkg triplet files
• spack specs

[mwoehlke]

Same way you support any flavor of any library? I'm not convinced there's anything special about the standard library in this regard.

I think the real issue here is that we're discussing things that don't ultimately resolve to -l, but to "magical" compiler and/or linker flags that need to have special rules about how you combine them. (At least, unless we want to go the route that you can't build your C++14 project against any library that uses C++17. And even then, we'd have to resort to components that use compile_flags, which experience has taught at least CMake are better avoided.)

CMake added CXX_LANGUAGE_LEVEL for a reason. Let's be very careful we know what we're doing before we remove the ability to express that.