[libcxx-commits] [libcxx] [libc++][modules] Mark as implemented. (PR #90091)

[Mark de Wever via libcxx-commits]

mordante wrote:

> I think we'd need to make the FTM conditional on whether modules are installed (via `LIBCXX_INSTALL_MODULES`). In the long term, I think this also means that we'll want to simply drop `LIBCXX_INSTALL_MODULES` and always install them when we install the libc++ headers, i.e. `LIBCXX_INSTALL_HEADERS` would imply that we install the modules files as well.

I dislike that idea; installation does not mean the vendor ships it at all. So we don't have a good way to detect whether modules are really supported. Several FTM depend on the dylib, these are also available unconditionally even when vendors can turn of  `LIBCXX_INSTALL_LIBRARY`. Since modules require headers and the dylib, I also prefer to keep the separate installation flag.

> > IMO in general we document what we do not what vendors do. For example, we mark features as implemented even when Apple decides not to make them available on backdeployment targets. (I understand why Apple does not want to do that.).
> 
> Just to clarify, Apple doesn't "make features unavailable on backdeployment targets". It's simply that new features that require dylib support can't work on older targets that don't have said support and we happen to care enough about users to have the availability machinery to let users know at compile-time (instead of crashing at load-time). Any system that uses shared libraries and ships libc++ as part of the operating system would experience exactly the same limitations. Just clarifying for readers cause your initial statement made it look a bit like Apple deliberately made things unsupported on older platforms, which is not true and would be a questionable practice.

Thanks. It was not my intention to suggest malice on Apple's side. It was just the first example that came to mind where feature-test macros are not always correct.

https://github.com/llvm/llvm-project/pull/90091