Re: [libgpiod][PATCH V9 0/8] libgpiod: Add Rust bindings

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Thu, Nov 17, 2022 at 12:15 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
>
> On 17-11-22, 12:05, Bartosz Golaszewski wrote:
> > So it already only impacts developers exclusively and not users who'd
> > for example want to install libgpiod from crates.io? If so then I
> > don't really see a reason to keep those files in the repo really.
>
> Users are impacted in the sense that they will be forced to build the bindings
> using bindgen now, automatically of course. It is an extra, time consuming,
> operation which can be avoided. For rust-vmm projects, every pull request
> results in fresh rebuild of the entire crate, which would mean two additional
> bindgen builds too, just for gpio now. It isn't a huge problem, but it is time
> that could have been saved.
>

If build-time is the only issue then I vote for automatic generation
at build-time and not storing those files.

> > I'm not familiar with rust-vmm containers but the fact that bindgen
> > support is missing or causes problems sounds like a problem with
> > rust-vmm and not users of bindgen, right?
>
> Yeah it can be, but IIUC, in the Rust world, more often than not such bindings
> are pre-generated, as this basically is Rust code only. These bindings will
> only change if we make a change to the gpiod API.
>

Leaving space for maintainer errors when preparing releases I suppose.
I don't know what the reason is for the Rust world to go that way but
more often than not, files that are generated automatically are not
checked in into repositories. This is my experience from working with
Qt, GLib or the linux kernel (flex and bison files generated by
kconfig).

> Perhaps that's why I was asked to avoid generating the bindings there, but I can
> ask again and try fixing the rust-vmm containers if it doesn't work.
>

Yes, if there's no show-stopper then let's generate the files at
build-time which also fixes the licensing issue.

Bart