https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215193
--- Comment #15 from Mark Millard <marklmi26-f...@yahoo.com> --- (In reply to Gleb Popov from comment #13) While I do not know how much libc++ is used, "base" does have c++ code that needs to be built and requiring a port/package to build the world is not commonly done. Seems unlikely that c++ would be eliminated from FreeBSD's world, even if the toolchain were made less public. Making /usr/include/c++ private/internal to FreeBSD instead would require changes to how the world is built so that the process references the FreeBSD-private copy. (I ignore here that making the astonishing change to a very public interface that is heavily used at this point is huge issue on its own.) Changes to the ports tree to well avoid mixes of differing libc++'s being mixed together in linking and/or run-time binding is also its own issue. Being able to support fully up to date libc++ based builds on such a grand scale may be more than is reasonable for all I know. But, as, stands, even a program that involves no dependencies outside the toolchain and libc++ has no means of using the most modern ports-supported llvm's libc++ (since it is not available as stands). Another type of example is use of 'import std.compat;' or 'import std;' . The imports are not references to globally invariant copies of files. Imports of either of those is handled by the likes of cmake to produce supporting files that are specific to the compiler options in use for what is being built. But for, say, cmake to do so means configuring the toolchain to provide extra information that is used by cmake (in this example, as worded). It does not look all that likely that FreeBSD's built-in toolchain configuration will support such. As far as I can tell, devel/llvm* using the system libc++ might not be able to(?). If modern enough lang/llvm* also does not support such, that blocks some basic (but new) c++ language+library functionality. (My wording ignores that cmake does not claim to have its final supported form for supporting such imports. The example is somewhat forward looking if one ignores exploring the existing llvm/cmake support combination. But it is still relevant for figuring out how to go forward and what is supported vs. not overall in the future.) -- You are receiving this mail because: You are the assignee for the bug.
