On Thu, Sep 26, 2024 at 05:40:19PM +0200, Miguel Ojeda wrote: > On Tue, Sep 17, 2024 at 5:26 PM Conor Dooley <conor@xxxxxxxxxx> wrote: > > > > Yes, but unfortunately I already knew how it worked. It's not flags I am worried about, it is extensions. > > Even using a libclang that doesn't match clang could be a problem, but we can at least declare that unsupported. > > Not digging it out on an airport bus, but we discussed the lack of GCC support on the original patch adding riscv, and decided against it. > > Do you mean you would prefer to avoid supporting the mixed GCC-Clang > builds? Mixed builds are allowed on the c side, since we can figure out what the versions of each tool are. If there's a way to detect the version of libclang in use by the rust side, then I would be okay with mixed gcc + rustc builds. > If so, do you mean you would prefer to not pick the patch, > i.e. avoid supporting this at all? Yes, I would rather this was not applied at all. My plan was to send a patch making HAVE_RUST depend on CC_IS_CLANG, but just ain't got around to it yet, partly cos I was kinda hoping to mention this to you guys at LPC last week, but I never got the chance to talk to any rust people (or go to any rust talks either!). > (If so, then perhaps it would be a > good idea to add a comment there and perhaps a note to > https://docs.kernel.org/rust/arch-support.html). Sure, I can add a comment there. > Otherwise, please let me know if I am misunderstanding -- thanks! In sorta related news, is there a plan for config "options" that will allow us to detect gcc-rs or the gcc rust backend? Cheers, Conor.
Attachment:
signature.asc
Description: PGP signature
