marker
buck2
Our great sponsors
marker | buck2 | |
---|---|---|
2 | 31 | |
136 | 3,259 | |
5.9% | 3.0% | |
9.4 | 10.0 | |
3 months ago | about 8 hours ago | |
Rust | Rust | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
marker
-
Blog Post: Next Rust Compiler
Check out this, which aims to implement said stable interface!
-
1Password releases Typeshare, the "ultimate tool for synchronizing your type definitions between Rust and other languages for seamless FFI"
Hey, I might be able to give some input how I deal with it in [rust-linting](https://github.com/rust-linting/rust-linting). For some context, the project needs to load several dynamic libraries and provide each of them with an abstract syntax tree. Serializing and deserializing the types for every step would most likely be too expensive. That's why I opted for a Rust <-> Rust FFI. There are two parts of this: 1. The loaded libraries needed to accept data from a driver. For this, I generate functions in the library crates which are marked as `extern "C"` and only use FFI safe types. Passing information to the loaded crates then always calls the generated functions, which intern call access a thread local struct instance in the dynamic crate. It's important that the instance implement a specific trait. For the library creation, it seems like magic. 2. Callbacks. The loaded libraries need to pass information back to the driver. For this, I use a struct with function pointers. These are also marked as `extern "C"` and need to only use FFI safe types. The definition of FFI safe, is a bit difficult. Slices, `str`, `Option<>` and most of the rusts STD types don't have a stable layout to the point, that it can change between compilations with the same compiler. Therefore, it's required that each passed type is `#[repr(C)]`. Options are wrapped in an enum, which has `#[repr(C)]`, slices and strings are dismantled into a data pointer and a length. On the receiving and they're reconstructed again. A small warning. I'm not an expert on FFI interfaces. My implementation would probably have some problems with lifetimes, if I'd use a slightly different memory model. So far, this has worked well (Besides the required boilerplate). The project is currently sadly lacking documentation, as it's still under heavy development. If you want, feel free to lock around the code base. The stable types and most of the interface is inside the `linter_api` crate.
buck2
-
Tech Debt: My Rust Library Is Now a CDO
https://buck2.build/ https://github.com/facebook/buck2
Rust support is also rather good ;) https://github.com/facebookincubator/reindeer
-
Things I learned while building projects with NX
Buck 2 by Facebook
-
Declarative Gradle is a cool thing I am afraid of: Maven strikes back
NOTE: I won’t mention SBT and Leiningen here because, with all due respect, they are niche build tools. I also won’t discuss Kobalt for the same reason (besides, it’s no longer actively maintained). Additionally, I won’t touch upon Bazel and Buck in this context, mainly because I’m not very familiar with them. If you have insights or comments about these tools, please feel free to share them in the comments 👇
-
Reason to use other Build Tool than Make?
There're tools which do this, for example https://bazel.build/, and https://buck2.build/ However they have a learning curve, which might be steep for some folks.
There's a new build system which works on similar ideas to buck: https://buck2.build/
-
Hello r/Rust! We are Meta Engineers who created the Open Source Buck2 Build System! Ask us anything! [Mod approved]
Great question! Our approach has been to use Bxl (https://buck2.build/docs/developers/bxl/) to script up operations that call various subtargets like `[compilation-database]` for `cxx_library`. I don't think all these pieces are open source yet, but https://github.com/facebook/buck2/blob/main/prelude/rust/rust-analyzer/resolve_deps.bxl is a snippet that is used to drive Rust Analyzer. Bxl does seem to be the "missing piece" for mapping between what the build system wants and what the IDE wants. But there's still a bunch of work after you get there to plumb into LSP.
I don't think all these pieces are open source yet, but https://github.com/facebook/buck2/blob/main/prelude/rust/rust-analyzer/resolve_deps.bxl is a snippet that is used to drive Rust Analyzer
See https://github.com/facebook/buck2/tree/main/shim/third-party/rust/fixups for the list of fixups. I'd say it is slightly trending down, as more people stabilise around libraries such as rustix for OS-specific functionality. But I'd say that a better approach would be for Reindeer to ship a default set of fixups for most common libraries, so it was shared. We haven't tracked fixups over time.
The recent blog about Buck2 and our GitHub.
The way it's done internally (and which we think is a good way to do it) is to implement the linter in two stages. In your Buck rules, you have something that produces outputs that describe transformations that need to be done, then an external binary calls Buck2 to produce those outputs. That binary can then apply the transformations that were requested. There are some examples and a bit more discussion over here: https://github.com/facebook/buck2/issues/115 -Thomas O. What are the long term plan to manage prelude / third party rules? I.e. if there is a repository for rules typescript / ruby, how should a user go about downloading them and keeping the version up-to-date?
What are some alternatives?
turbo - Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turbopack and Turborepo.
Bazel - a fast, scalable, multi-language and extensible build system
rfcs - RFC process for Bytecode Alliance projects
Vcpkg - C++ Library Manager for Windows, Linux, and MacOS
buck2-prelude - Prelude for the Buck2 project
PyOxidizer - A modern Python application packaging and distribution tool
HHVM - A virtual machine for executing programs written in Hack.
minio - The Object Store for AI Data Infrastructure
reduze - Zig program reduction is upstream in compiler due to various parser + formatter interactions.
librunecoral
depot - @ghuntley's personal monorepo [Moved to: https://github.com/ghuntley/ghuntley]