node-cpp-skel uses mason-js to download an optimal, consistent compiler. This unlocks reliable and powerful build tooling like clang-tidy, clang-format, the sanitizers, and LTO.
Problem
The LLVM 6.0.0 sub-packages of clang++ and clang-tidy both contains the libc++ headers in include/c++/v1.
These should both be symlinks on OS X to the system Xcode.app by design in mason. But in the 6.0.0 package the clang++ headers are not a symlink and are actually a full copy of the C++ headers. This is fine except for when linking with mason-js. In this situation the clashing differences lead to this tricky bug mapbox/mason-js#58.
I don't have a good solution yet to mapbox/mason-js#58. Landing mapbox/mason#620 and issuing a new LLVM package would also fix this. But until then I think we should revert to LLVM 5.0.1 and subpackages to avoid the error of:
V=1 ./node_modules/.bin/node-pre-gyp configure build --error_on_warnings=true --loglevel=error
LD_LIBRARY_PATH=/Users/mthompson/src/node-cpp-skel/build/Release/lib.host:/Users/mthompson/src/node-cpp-skel/build/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../.; mkdir -p ./mason_packages; ./node_modules/.bin/mason-js link
info Symlinked: /Users/mthompson/src/node-cpp-skel/mason_packages/headers/protozero/1.6.1 to /Users/mthompson/src/node-cpp-skel/mason_packages/.link
ERR! Error: EACCES: permission denied, unlink '/Users/mthompson/src/node-cpp-skel/mason_packages/.link/include/c++/v1/__bit_reference'
make[1]: *** [mason_packages/.link] Error 1
Context
node-cpp-skel uses mason-js to download an optimal, consistent compiler. This unlocks reliable and powerful build tooling like clang-tidy, clang-format, the sanitizers, and LTO.
Problem
The LLVM 6.0.0 sub-packages of
clang++andclang-tidyboth contains thelibc++headers ininclude/c++/v1.These should both be symlinks on OS X to the system Xcode.app by design in mason. But in the 6.0.0 package the
clang++headers are not a symlink and are actually a full copy of the C++ headers. This is fine except for when linking with mason-js. In this situation the clashing differences lead to this tricky bug mapbox/mason-js#58.I don't have a good solution yet to mapbox/mason-js#58. Landing mapbox/mason#620 and issuing a new LLVM package would also fix this. But until then I think we should revert to LLVM 5.0.1 and subpackages to avoid the error of:
/cc @mapbox/core-tech @alliecrevier @millzpaugh