<div dir="ltr">Hi guys,<div><br></div><div>This is no versioning question. I think when the host,target is not equal to build (I mean configure options --build,--taget,--host) we can compile two scanners:</div><div><br></div><div>1) scanner built by cross compiler and has original name (wayland-scanner)</div><div>2) scanner built by BUILD_CC and has complex name, for example, arm-xxx-linux-gnueabihf-<wbr>wayland-scanner (this scanner can be in the non install binaries list)</div><div><br></div><div>That is all.</div><div><br></div><div>In this case the engineer who prepare the package can make decision about installation the second scanner into his development environment (in the same way as cross-compiler in his toolchain) to be able using this build-machine scanner for build other packages for the same target machine.</div><div><br></div><div>I think it is not too complex but allows to build sources in one stage.</div><div><br></div><div>Best Regards,</div><div>Andrey K.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 5, 2016 at 1:01 PM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 2 Dec 2016 17:06:29 +0000<br>
Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote:<br>
<br>
> On 2 December 2016 at 14:55, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
> > On Fri, 8 Jul 2016 11:29:16 +0100<br>
> > Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote:<br>
> ><br>
> >> Hi all,<br>
> >><br>
> >> Jumping the gun a bit, hope you'll forgive me :-)<br>
> >><br>
> >> On 8 July 2016 at 09:17, Quentin Glidic <<a href="mailto:sardemff7%2Bwayland@sardemff7.net">sardemff7+wayland@sardemff7.<wbr>net</a>> wrote:<br>
> >> > On 18/05/2016 14:55, Andrew Kosteltsev wrote:<br>
> >><br>
> >> >> Then the user can make use this cross-wayland-scanner in his SDK, for<br>
> >> >> example, like follow:<br>
> >> >><br>
> >> >> $ ../MesaLib-10.3.4/configure<br>
> >> >> WAILAND_SCANNER=$(SDK_DIR)/<wbr>bin/$(target)-wayland-scanner<br>
> >> >><br>
> >> Afaict newer mesa releases should include the generated files. Thus<br>
> >> one shouldn't need to use the tool, let alone have it.<br>
> >><br>
> >> If anything I'd suggest pinging the respective projects to provide<br>
> >> complete/comprehensive release tarballs.<br>
> ><br>
> > Hi Emil,<br>
> ><br>
> > that would make the project release tar-ball depend on the libwayland<br>
> > version of the system where the tar-ball was created. Are you sure you<br>
> > want that?<br>
> ><br>
> Based on my understanding of how release tarball should behave - yes.<br>
<br>
</span>And people who make the release tar-balls pay attention to which<br>
library version dependency they impose? Will it match the required<br>
library version in <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a>?<br>
<br>
I agree, it is very annoying and could use fixing, but again, this is<br>
the situation right now if we added something new in the scanner.<br>
<span class=""><br>
> > You probably want to fix it in wayland-scanner instead, but that is not<br>
> > the reality today, yet. It only works because we haven't changed the<br>
> > scanner incompatibly for quite some time now.<br>
> ><br>
> > I suppose this is the reason you wanted to have the versioning options<br>
> > in wayland-scanner. It never occurred to me that people would be<br>
> > shipping the generated files. You don't put them into VCS either, and<br>
> > Weston takes care to not ship them.<br>
> ><br>
> There's a couple of ideas which come to mind, why Weston does not ship<br>
> the files:<br>
>  - Thinko ? Similar to how the interface symbols are _explicitly_<br>
> exported while devs lean that each project should have them<br>
> statically.<br>
<br>
</span>Partly, perhaps, due to the below.<br>
<span class=""><br>
>  - The API/ABI generated by wayland-scanner is intentionally meant to<br>
> be fluid ? Seriously doubt this is the case.<br>
<br>
</span><a href="https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Code-Generation" rel="noreferrer" target="_blank">https://wayland.freedesktop.<wbr>org/docs/html/ch04.html#sect-<wbr>Protocol-Code-Generation</a><br>
<br>
Things that wayland-scanner generates are explicitly not part of the<br>
library provided ABI. They *are* part of the library API on the parts<br>
that the library actually installs.<br>
<br>
When libwayland is updated, we obviously need to keep existing binaries<br>
working. That implies that code generated by old scanners need to keep<br>
on working in binaries.<br>
<br>
I do not think that building with a new scanner and then running<br>
against an old libwayland has been considered a worthwhile use case. So<br>
far at least I have always considered that libwayland and scanner<br>
versions only need to keep existing binaries working.<br>
<br>
Do distributions build packages against the latest library versions<br>
even though they (want to) guarantee the packages working with older<br>
libraries too?<br>
<br>
If yes, I suppose that's the oversight at upstream.<br>
<span class=""><br>
> And yes this is one example/reason why we want the scanner to provide<br>
> a consistent API/ABI/other. Unless the user explicitly opts out.<br>
<br>
</span>I'm looking forward to proposals for that, I think for the development<br>
cycle that starts in Feb, because I this is probably something we<br>
should land early in the cycle.<br>
<br>
It is also the reason I pointed you to the patch that deprecates<br>
*_add_listener() and renames it to *_set_listener(), since that would<br>
be a complex use case touching everything: libwayland API and ABI, and<br>
scanner.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div>