Pierrick Bouvier <pierrick.bouv...@linaro.org> writes: > On 6/10/24 13:29, Manos Pitsidianakis wrote: >> On Mon, 10 Jun 2024 22:37, Pierrick Bouvier <pierrick.bouv...@linaro.org> >> wrote: >>> Hello Manos, >>> <snip> >>> Excellent work, and thanks for posting this RFC! >>> >>> IMHO, having patches 2 and 5 splitted is a bit confusing, and exposing >>> (temporarily) the generated.rs file in patches is not a good move. >>> Any reason you kept it this way? >> That was my first approach, I will rework it on the second version. >> The >> generated code should not exist in committed code at all. >> It was initally tricky setting up the dependency orders correctly, >> so I >> first committed it and then made it a dependency. >> >>> >>> Maybe it could be better if build.rs file was *not* needed for new >>> devices/folders, and could be abstracted as a detail of the python >>> wrapper script instead of something that should be committed. >> That'd mean you cannot work on the rust files with a LanguageServer, >> you >> cannot run cargo build or cargo check or cargo clippy, etc. That's why I >> left the alternative choice of including a manually generated bindings >> file (generated.rs.inc) >> > > Maybe I missed something, but it seems like it just checks/copies the > generated.rs file where it's expected. Definitely something that could > be done as part of the rust build. > > Having to run the build before getting completion does not seem to be > a huge compromise. > <snip>
As long as the Language Server can kick in after a first build. Rust definitely leans in to the concept of the tooling helping you out while coding. I think for the C LSPs compile_commands.json is generated during the configure step but I could be wrong. -- Alex Bennée Virtualisation Tech Lead @ Linaro
