<div dir="ltr"><div dir="ltr">On Sun, Sep 20, 2020 at 5:39 PM Alexandre Janniaux <<a href="mailto:ajanni@videolabs.io">ajanni@videolabs.io</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Sun, Sep 20, 2020 at 05:21:55PM +0530, Kartik Ohri wrote:<br>
> On Sun, Sep 20, 2020 at 4:48 PM Alexandre Janniaux <<a href="mailto:ajanni@videolabs.io" target="_blank">ajanni@videolabs.io</a>><br>
> wrote:<br>
> > The point of using Meson integration is actually that it is<br>
> > limited. ;)<br>
> ><br>
> > In my opinion, it would also greatly simplify the build<br>
> > definitions by removing toml files, greatly decrease<br>
> > compilation time if we are to integrate more Rust, and<br>
> > provide a unified build system that all developers will<br>
> > manipulate, be them Rust developers or not, so making the<br>
> > Rust integration quite like the C++ one.<br>
> ><br>
> ><br>
> Makes sense. I do not currently know how we could do without toml files.<br>
> Rust ecosystem is heavily centered around cargo. More research is required<br>
> into working of meson and cargo to understand how we should approach this.<br>
> At the least it seems we would have to give up using external crates which<br>
> may or may not be a hindrance. The cargo.toml files are pretty minimal and<br>
> will be almost similar for all modules. However, that may be only me.<br>
<br>
Actually no, you can have a converter for Rust toml project<br>
into meson subprojects in a few lines of code, it gets a bit<br>
more difficult with build.rs-based builds but we could just<br>
try to prevent them as much as possible.<br>
<br>
We can probably defer this to until we get meson in-tree<br>
though, but it might need preliminary care about what we<br>
integrate.<br>
<br></blockquote><div>Yes certainly makes sense, we should not use any external crate in the rust modules till the point we can figure this out. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In particular, it means that crates will need to go into the<br>
contrib system, and some crates are likely to need the world<br>
to be compiled, or very specific version of some libraries<br>
without rational. Such crate should be avoided or modified<br>
upstream in my opinion. And finally we might need scripts to<br>
update the contrib system crates version according to what<br>
<a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a> tells us is compatible with (I don't think we want<br>
to ship multiple times the same crate just like we will with<br>
the current cargo/contrib integration).<br>
<br>
It might also be interesting to check debian's packaging for<br>
crates, which could bring a symmetrical situation with all<br>
the non-rust dependencies in the current tree through usual<br>
tools like pkg-config.<br>
<br></blockquote><div>Yeah, that would be a good avenue to explore and be beneficial. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Rust ecosystem is heavily centered around cargo.<br>
<br>
While I agree with this, and it's certainly much easier<br>
to start with this, Rust is just yet another programming<br>
language and though the first experience and crate/cargo<br>
experience is really good, my point is that it's not<br>
necessarily suitable in every situation and in particular<br>
in cross-language with multiple targets projects. Meson<br>
is likely to be the best tradeoff regarding those complex<br>
constraints.<br>
<br></blockquote><div>Agreed. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards,<br>
--<br>
Alexandre Janniaux<br>
Videolabs<br>
_______________________________________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="https://mailman.videolan.org/listinfo/vlc-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/vlc-devel</a></blockquote></div></div>