[vlc-devel] [PATCH 1/2] libvlc: Add Rust API for writing modules in rust

[Kartik Ohri]

On Sun, Sep 20, 2020 at 5:39 PM Alexandre Janniaux <ajanni at videolabs.io>
wrote:

> Hi,
>
> On Sun, Sep 20, 2020 at 05:21:55PM +0530, Kartik Ohri wrote:
> > On Sun, Sep 20, 2020 at 4:48 PM Alexandre Janniaux <ajanni at videolabs.io>
> > wrote:
> > > The point of using Meson integration is actually that it is
> > > limited. ;)
> > >
> > > In my opinion, it would also greatly simplify the build
> > > definitions by removing toml files, greatly decrease
> > > compilation time if we are to integrate more Rust, and
> > > provide a unified build system that all developers will
> > > manipulate, be them Rust developers or not, so making the
> > > Rust integration quite like the C++ one.
> > >
> > >
> > Makes sense. I do not currently know how we could do without toml files.
> > Rust ecosystem is heavily centered around cargo. More research is
> required
> > into working of meson and cargo to understand how we should approach
> this.
> > At the least it seems we would have to give up using external crates
> which
> > may or may not be a hindrance. The cargo.toml files are pretty minimal
> and
> > will be almost similar for all modules. However, that may be only me.
>
> Actually no, you can have a converter for Rust toml project
> into meson subprojects in a few lines of code, it gets a bit
> more difficult with build.rs-based builds but we could just
> try to prevent them as much as possible.
>
> We can probably defer this to until we get meson in-tree
> though, but it might need preliminary care about what we
> integrate.
>
> Yes certainly makes sense, we should not use any external crate in the
rust modules till the point we can figure this out.

> In particular, it means that crates will need to go into the
> contrib system, and some crates are likely to need the world
> to be compiled, or very specific version of some libraries
> without rational. Such crate should be avoided or modified
> upstream in my opinion. And finally we might need scripts to
> update the contrib system crates version according to what
> crates.io tells us is compatible with (I don't think we want
> to ship multiple times the same crate just like we will with
> the current cargo/contrib integration).
>
> It might also be interesting to check debian's packaging for
> crates, which could bring a symmetrical situation with all
> the non-rust dependencies in the current tree through usual
> tools like pkg-config.
>
> Yeah, that would be a good avenue to explore and be beneficial.

> > Rust ecosystem is heavily centered around cargo.
>
> While I agree with this, and it's certainly much easier
> to start with this, Rust is just yet another programming
> language and though the first experience and crate/cargo
> experience is really good, my point is that it's not
> necessarily suitable in every situation and in particular
> in cross-language with multiple targets projects. Meson
> is likely to be the best tradeoff regarding those complex
> constraints.
>
> Agreed.

> Regards,
> --
> Alexandre Janniaux
> Videolabs
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200920/f7d6e3ca/attachment.html>