If there are no other comments I would like to soon push the patches I have on gerrit as the review is coming to a conclusion:
https://review.coreboot.org/c/flashrom/+/65280 https://review.coreboot.org/c/flashrom/+/65281 These add rust libraries to the bindings/rust/libflashrom{,-sys} paths and exclude those from tarball creation. On Wed, 3 Aug 2022 at 09:49, Evan Benn <evanb...@chromium.org> wrote: > > On Sun, 31 Jul 2022 at 07:28, Felix Singer <felixsin...@posteo.net> wrote: > > > > Hi all, > > > > I'm also fine with having this in the flashrom repository. As I > > understand it, you are just playing around currently. As long as this > > is not hooked up to the build system during this phase (to avoid > > problems), I don't see a problem here. > > I do intend to get this submitted soon, and in chromeos we will be using > > flashrom_tester -> rust bindings -> libflashrom > > to 'AVL' qualify new flash chips for inclusion in chromeos devices. > > > > > Though, when the plans and ideas get more concrete, then it might make > > sense to use a separate repository for it. But let's see where this > > goes :) > > > > // Felix > > > > > > On Sat, 2022-07-30 at 19:24 +0000, Thomas Heijligen wrote: > > > Hi Evan, Greg, > > > sorry for my late response. > > > > > > I'm fine with having language bindings in the flashrom repository. > > > Especially when a user of those bindings lives also in the > > > repository. > > > But then we have to find a way to make building everything convenient > > > for developers and distributers. > > > The other solution would be to create new repositories in gerrit for > > > the bindings and the user of it. This would imply that we fix our api > > > versioning first. > > The API versioning does sound like a big topic, I do prefer to > continue in the same > repo if possible as it does sidestep those issues for now. When a > strong libflashrom > versioning story emerges we can move things around. The rust binding > uses -pre 1.0 > versioning to indicate that there is no compatibility between versions. > > For packaging I can exclude the rust bindings from the flashrom > tarball, and to make > a rust binding tarball `cargo package` can be used. > > > > > > > Imo the separate repositories in combination with some gerrit bots > > > might be the best solution to make everyone happy. But I'll support > > > you, Evan, on the solution you will choose. > > > > > > -- Thomas > > > > > > On 20 July 2022 01:28:34 CEST, Evan Benn <evanb...@chromium.org> > > > wrote: > > > > On Tue, 19 Jul 2022 at 03:46, Greg Troxel <g...@lexort.com> wrote: > > > > > > > > > > > > > > > Evan Benn <evanb...@chromium.org> writes: > > > > > > > > > > > I think the first question is is the flashrom community happy > > > > > > to have > > > > > > these bindings live inside the flashrom git repo? They could > > > > > > live in > > > > > > their own separate repos, but keeping them with flashrom will > > > > > > make > > > > > > keeping up with libflashrom API changes more straightforward. > > > > > > > > > > > > > > > > I am more or less an outsider, but as a packager: > > > > > > > > > > I do not want the binding to be hooked into the main build > > > > > system. > > > > > > > > > > Building flashrom is one thing, and I expect that to work > > > > > pretty much > > > > > everywhere. > > > > > > > > > > > > > > > > > > Good point, I will make sure the bindings are not part of the build > > > > system. > > > > > > > > > Building the rust bindings I expect to be not wanted by > > > > > everyone who > > > > > wants flashrom, to have heavier dependencies (rustc is > > > > > beastly), and > > > > > to have signficant portability problems. That's all fine, but > > > > > if in > > > > > the same release tarball there should be a way to cd to some > > > > > subdir, > > > > > and build, expecting that flashrom is already installed and > > > > > using the > > > > > installed headers and libs, and expecting a rust compiler. > > > > > > > > > > I don't care at all about upstream repo organization if the > > > > > rust > > > > > binding is its own release tarball. > > > > > > > > > > > > > I agree, the bindings do not need to go in the flashrom tarball. > > > > > > > > > > > > > > I'll observe that changes to libflashrom and changes to the > > > > > bindings > > > > > may not be connected. > > > > > > > > > > Given all of the above, I think it's better to have each > > > > > language > > > > > binding be a separate repo with separate release tarballs. > > > > > > > > > > > > > I see it is possible to exclude files from the archive using > > > > .gitattributes, > > > > but that does not make it easy to publish a libflashrom-rust- > > > > bindings > > > > archive separately. > > > > > > > > Does anyone know the process or contact for creating a new archive > > > > on > > > > review.coreboot.org? > > > > > > > > Thanksflashrom mailing list -- flashrom@flashrom.org > > > > To unsubscribe send an email to flashrom-le...@flashrom.org > > > _______________________________________________ > > > flashrom mailing list -- flashrom@flashrom.org > > > To unsubscribe send an email to flashrom-le...@flashrom.org > > _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
