This reverts commit 13aff21f,
since the CMake part relanded in c06a8f9c.

The GN part is a bit simpler than last time due to the
prior simplifications in acea470c.

$ git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format

We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

Differential Revision: https://reviews.llvm.org/D95956

- Merge 6706342f -- no more libcxx_needs_site_config, we now
  always need it
- Since it was always off in practice, write_config bitrot. Unbitrot
  it so that it works
- Remove copy step and let concat step write to final location
  immediately -- and fix copy destination directory

As a side effect, libcxx/include/BUILD.gn now has only a single
sources list, which means the cmake sync script should be able to
automatically sync additions and removals of .h files. On the flipside,
this means this file now must be updated after most changes to
libcxx/include/__config_site.in, and looking through the last few months
of changes this looks like it's going to be a wash.

I noticed __availability was missing, so I manually diffed the
file lists and put all recently(ish) added headers:
* __availability from 2eadbc86
* concepts from 601f7631
* execution from 0a06eb91
* numbers from 4f6c4b47

Also remove libcxx_install_support_headers like the CMake build did in
6706342f, and unconditionally copy
support/win32/{limits_msvc_win32.h,locale_win32.h} like the CMake
build always did as far as I can tell.

This reverts commit 37a1336d.
173b5116 was reverted in 777ca48c.

This reverts commit b3ca53e1.
This reverts commit 8b7dac81.
This reverts commit 37c030f8.

37c030f8 made it so that depending on //libcxx/include
automatically added the copied header dir to the include search path.
For some reason, clang can't build against the copied libcxx headers
(it complains about ldiv_t not being a type). I don't have a mac
to debug right now, but for the clang target this change was
unintentional anyways -- only depend on the copies target, instead
of on the target that also adjusts the include path.

The write_cmake_config() here still looks busted, but at least
the value that's explicitly set is now set correctly.

On macOS, libc++ headers are distributed with the compiler, not
the sysroot. Without this, compiling a file that includes something
like <string> won't compile with gn-built clang without manual tweaks.

I used to do the manual tweaks, but now that other people are starting
to use this on mac, let's make it Just Work.

(This is marginally nicer than the cmake build now in that you can
just build 'clang' and it'll do the right thing.)

Differential Revision: https://reviews.llvm.org/D74247

llvm-svn: 364015

llvm-svn: 364004

This was omitted in r359805.

Differential Revision: https://reviews.llvm.org/D61462

llvm-svn: 359828

This change introduces support for building libc++. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.

We only support two stage build at the moment.

Differential Revision: https://reviews.llvm.org/D61143

llvm-svn: 359806