qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
To: Pierrick Bouvier <pierrick.bouvier@linaro.org>, qemu-devel@nongnu.org
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Mads Ynddal" <mads@ynddal.dk>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alex Benn é e" <alex.bennee@linaro.org>,
	"Daniel P. Berrangé " <berrange@redhat.com>,
	"Marc-Andr é Lureau" <marcandre.lureau@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Philippe Mathieu-Daud é " <philmd@linaro.org>,
	"Zhao Liu" <zhao1.liu@intel.com>,
	"Gustavo Romero" <gustavo.romero@linaro.org>
Subject: Re: [RFC PATCH v1 0/6] Implement ARM PL011 in Rust
Date: Tue, 11 Jun 2024 08:47:11 +0300	[thread overview]
Message-ID: <ewiz1.q2hs3ao1amn@linaro.org> (raw)
In-Reply-To: <6e7a14a1-8727-4ce5-ae67-797323704464@linaro.org>

On Tue, 11 Jun 2024 00:38, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>> 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.

It only checks if it's called from meson, hence it should update the 
should choose meson's generated.rs file. Otherwise it falls back to any 
manual bindings you have put there that are not checked into git. So 
essentially it does what you suggest, I think :)


>>
>> Yes, vendor-the-world is a different topic than vendor e.g. two 
>> crates such as the dependencies I'm using here.
>>
>
>If there must be a discussion about dependencies, it's probably better 
>to consider the "worse" case to take a decison about vendoring this or not.
>

Agreed. To re-cap, my opinion is that vendoring 1-2 small crates is 
fine, but any more than that needs rethinking.


  reply	other threads:[~2024-06-11  5:52 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10 18:22 [RFC PATCH v1 0/6] Implement ARM PL011 in Rust Manos Pitsidianakis
2024-06-10 18:22 ` [RFC PATCH v1 1/6] build-sys: Add rust feature option Manos Pitsidianakis
2024-06-10 19:25   ` Stefan Hajnoczi
2024-06-11 14:19     ` Alex Bennée
2024-06-11 17:53     ` Manos Pitsidianakis
2024-06-11 18:25       ` Stefan Hajnoczi
2024-06-12  8:04         ` Daniel P. Berrangé
2024-06-12  8:25           ` Marc-André Lureau
2024-06-10 18:22 ` [RFC PATCH v1 3/6] DO NOT MERGE: add rustdoc build for gitlab pages Manos Pitsidianakis
2024-06-10 18:22 ` [RFC PATCH v1 4/6] DO NOT MERGE: replace TYPE_PL011 with x-pl011-rust in arm virt machine Manos Pitsidianakis
2024-06-10 18:22 ` [RFC PATCH v1 6/6] DO NOT MERGE: update rustdoc gitlab pages gen Manos Pitsidianakis
2024-06-10 19:37 ` [RFC PATCH v1 0/6] Implement ARM PL011 in Rust Pierrick Bouvier
2024-06-10 20:29   ` Manos Pitsidianakis
2024-06-10 21:38     ` Pierrick Bouvier
2024-06-11  5:47       ` Manos Pitsidianakis [this message]
2024-06-11  9:21       ` Alex Bennée
2024-06-11 15:32         ` Pierrick Bouvier
2024-06-11  8:02     ` Daniel P. Berrangé
2024-06-11  9:18       ` Alex Bennée
2024-06-11 10:57     ` Daniel P. Berrangé
2024-06-11 10:58       ` Manos Pitsidianakis
2024-06-11 11:09         ` Daniel P. Berrangé
2024-06-11 11:32           ` Manos Pitsidianakis
2024-06-11 12:51           ` Alex Bennée
2024-06-11 12:54             ` Daniel P. Berrangé
2024-06-11 12:45         ` Antonio Caggiano
2024-06-11 12:49           ` Manos Pitsidianakis
2024-06-10 19:59 ` Stefan Hajnoczi
2024-06-10 20:15   ` Manos Pitsidianakis
2024-06-10 20:47     ` Stefan Hajnoczi
2024-06-11  8:42       ` Daniel P. Berrangé
2024-06-11  9:30       ` Alex Bennée
2024-06-11 13:13       ` Paolo Bonzini
2024-06-11  8:11   ` Philippe Mathieu-Daudé
2024-06-11  8:18 ` Daniel P. Berrangé
2024-06-11  9:53   ` Zhao Liu
2024-06-11 10:50   ` Manos Pitsidianakis
2024-06-11  8:22 ` Daniel P. Berrangé
2024-06-11  9:45   ` Zhao Liu
2024-06-11 10:41     ` Manos Pitsidianakis
2024-06-11 14:32       ` Zhao Liu
2024-06-11 10:40   ` Manos Pitsidianakis
2024-06-11 13:16   ` Paolo Bonzini
2024-06-11 14:11     ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ewiz1.q2hs3ao1amn@linaro.org \
    --to=manos.pitsidianakis@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=gustavo.romero@linaro.org \
    --cc=mads@ynddal.dk \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    --cc=zhao1.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).