зеркало из https://github.com/mozilla/gecko-dev.git
985a376afa
The current setup for bindgen relies on either finding clang/libclang from the output of llvm-config, or from the paths given via the configure flags --with-clang-path/--with-libclang-path. One _very_ common problem is that the llvm-config we end up using does not correspond to the clang used for compilation, which has some undesirable side effect, like failing to build. So instead of relying on llvm-config, we do the following: - when the compiler is clang, we just use that - when the compiler is clang-cl, we use clang from the same directory - otherwise, we either try to find clang in PATH, or rely on --with-clang-path. Once clang is found, we try to deduce the location of the corresponding libclang via the output of `clang -print-search-dirs`, or rely on --with-libclang-path. Differential Revision: https://phabricator.services.mozilla.com/D33241 --HG-- extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| build-binutils | ||
| build-gcc | ||
| build-hfsplus | ||
| elfhack | ||
| stdc++compat | ||
| aix.exp | ||
| moz.build | ||
| mozconfig.asan | ||
| mozconfig.linux | ||
| mozconfig.linux32 | ||
| mozconfig.stdcxx | ||
| mozconfig.tsan | ||
| mozconfig.unix | ||
| mozilla.in | ||
| print-failed-commands.sh | ||
| print-non-newline.sh | ||
| rewrite_asan_dylib.py | ||
| run-gprof.sh | ||
| run-hiprof.sh | ||
| run-mozilla.sh | ||
| run-third.sh | ||