| commit | ad9ed1c59f18b658998ee495058bdf9cb6f6a91a | [log] [tgz] |
|---|---|---|
| author | Devin Jeanpierre <jeanpierreda@google.com> | Mon Jan 23 16:13:37 2023 -0800 |
| committer | Copybara-Service <copybara-worker@google.com> | Mon Jan 23 16:14:11 2023 -0800 |
| tree | 68e323832a614bdbba8047b00bf916e6508a5061 | |
| parent | 785e6b4b56f61d2d22130400b8ef40c66aeae9c4 [diff] |
Move remaining runtime libraries to `crubit/support`. This is not "obviously" correct: the current contents of crubit/support are only the runtime libraries that are present in generated code. But I don't think that's an important distinction -- rather, I think it's valuable to have all user-facing libraries in the same place. (I would be "support"-ive of basically any directory scheme that puts them together. An alternative design, for example, is to unwrap `support/*` into `third_party/crubit`, so that people depend on `crubit:foo` instead of `crubit/support:foo`. Alternatively, we could rename `support` to `public` or `lib`, but keep it as is. Or, finally, we can just keep it as is.) For now, moving into `support` makes it easier to find the user-facing libraries. PiperOrigin-RevId: 504107815
Extremely experimental interop tooling for C++ and Rust.
Please don‘t use, this is an experiment and we don’t yet know where will it take us. There will be breaking changes without warning. Unfortunately, we can't take contributions at this point.
$ apt install clang lld bazel $ git clone git@github.com:google/crubit.git $ cd crubit $ bazel build --linkopt=-fuse-ld=/usr/bin/ld.lld //rs_bindings_from_cc:rs_bindings_from_cc_impl
$ git clone https://github.com/llvm/llvm-project $ cd llvm-project $ CC=clang CXX=clang++ cmake -S llvm -B build -DLLVM_ENABLE_PROJECTS='clang' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=install $ cmake --build build -j $ # wait... $ cmake --install build $ cd ../crubit $ LLVM_INSTALL_PATH=../llvm-project/install bazel build //rs_bindings_from_cc:rs_bindings_from_cc_impl