<div dir="ltr">I meant to put [RFC] and not [NFC] in the title. Woops :-S</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 9:24 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">Hi All,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">This should be done such that:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">1) 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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">2) 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.<br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">3) 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.<br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">4) 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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">==========================</div><div style="font-size:12.8px">The Initial implementation (libc++fs)</div><div style="font-size:12.8px">==========================<br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The implementation of the filesystem TS will be provided by the libc++fs library, separate from the main DSO. All of the symbols in this library will be defined within the std::experimental namespace. Users of this library should not expect ABI compatibility and vendors who guarantee such compatibility should not ship this as part of their base system.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">During this time the C++17 implementation of std::filesystem can be provided as an</div><div style="font-size:12.8px">alias to std::experimental::filesystem. Users with minimal ABI concerns can use the C++17 API immediately without worrying about transitioning later. Vendors with ABI concerns can choose only to ship <experimental/filesystem> and not <filesystem>.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Goal #4 can be achieved with the use of linker scripts (except on OS X). During this time the default libc++ build will create libc++.so as a linker script that automatically links to libc++fs. Users are free to disable this behavior. (Suggestions are welcome on how to achieve goal #4 on OS X!).</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">By default libc++fs will build as a static library (except on OS X).</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">==========================</div><div style="font-size:12.8px">The Transition into the libc++ DSO</div><div style="font-size:12.8px">==========================</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Once libc++fs has matured the symbols will be moved into the main DSO and out of the experimental namespace. At this point the <filesystem> ABI will be considered stable and we can</div><div style="font-size:12.8px">begin to depreciate <experimental/filesystem>. By default libc++ will no longer build libc++fs.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">During this transition the implementation of <experimental/filesystem> will be removed and changed to simply refer to <filesystem> using a namespace alias. <span style="font-size:12.8px">No definitions for experimental symbols will be provided. This provides legacy API but with a different ABI. Programs compiled against libc++fs are not ABI compatible with newer programs that use filesystem.</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Some vendors, such as Apple, will continue to require libc++fs in order to package applications for older system. I believe it should be sufficient to provide libc++fs with a new ABI by using the same object files used to build the libc++ DSO. This means that libc++fs will contain the definitions in namespace std::filesystem instead of std::experimental::filesystem. Note that the new libc++fs ABI would still be compatible with older libc++ DSO's.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">=========</div><div style="font-size:12.8px">Conclusion</div><div style="font-size:12.8px">=========</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I hope I have been able to explain the plan and the rational for it.</div><div style="font-size:12.8px">Please ask for clarification if I've confused.</div><div style="font-size:12.8px"><span style="font-size:12.8px">Any and all feedback is appreciated.</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">/Eric</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="margin:2px 0px 0px;font-size:12.8px"><div><img src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div></div>
</blockquote></div><br></div>