Hi All,
How we package the newly standardized libraries will have an affect on users, vendors and the libc++ implementation. This email deals specifically with filesystem the same approach will be used for all new additions, include ASIO.
Our end goal is to package filesystem as part of the main libc++ DSO once the implementation has matured. Until that time we plan to ship the experimental implementation as a separate library, libc++fs.
This should be done such that:
-
There is a clear transition path from this temporary packaging strategy to the final one. This packaging transition should be feasible for vendors to implement. It should also be transparent for users (in regards to how they link their code). This transition strategy must allow libc++ to provide legacy API and ABI support.
-
It is possible to install and update the experimental filesystem separately from a system’s libc++ installation. Many vendors will not want to ship experimental stuff as part of their base systems but this should not prevent the use of <experimental/filesystem>. This is also important to allowing bug fixes to be applied without having to update the base system since such updates can take years. Once the implementation is no longer “experimental” this is no longer a requirement.
-
The ABI stability of the main libc++ DSO must be maintained while allowing ABI flexibility for the experimental FS symbols. This includes the ability to remove the std::experimental::filesystem symbols eventually.
-
Linking filesystem should be transparent to the end user. If the user is forced to manually link the filesystem library then changing these details will result in breakage.