Create cross wayland-scanner for toolchain or cross-development environment

[Pekka Paalanen]

On Fri, 2 Dec 2016 17:06:29 +0000
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> On 2 December 2016 at 14:55, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Fri, 8 Jul 2016 11:29:16 +0100
> > Emil Velikov <emil.l.velikov at gmail.com> wrote:
> >  
> >> Hi all,
> >>
> >> Jumping the gun a bit, hope you'll forgive me :-)
> >>
> >> On 8 July 2016 at 09:17, Quentin Glidic <sardemff7+wayland at sardemff7.net> wrote:  
> >> > On 18/05/2016 14:55, Andrew Kosteltsev wrote:  
> >>  
> >> >> Then the user can make use this cross-wayland-scanner in his SDK, for
> >> >> example, like follow:
> >> >>
> >> >> $ ../MesaLib-10.3.4/configure
> >> >> WAILAND_SCANNER=$(SDK_DIR)/bin/$(target)-wayland-scanner
> >> >>  
> >> Afaict newer mesa releases should include the generated files. Thus
> >> one shouldn't need to use the tool, let alone have it.
> >>
> >> If anything I'd suggest pinging the respective projects to provide
> >> complete/comprehensive release tarballs.  
> >
> > Hi Emil,
> >
> > that would make the project release tar-ball depend on the libwayland
> > version of the system where the tar-ball was created. Are you sure you
> > want that?
> >  
> Based on my understanding of how release tarball should behave - yes.

And people who make the release tar-balls pay attention to which
library version dependency they impose? Will it match the required
library version in configure.ac?

I agree, it is very annoying and could use fixing, but again, this is
the situation right now if we added something new in the scanner.

> > You probably want to fix it in wayland-scanner instead, but that is not
> > the reality today, yet. It only works because we haven't changed the
> > scanner incompatibly for quite some time now.
> >
> > I suppose this is the reason you wanted to have the versioning options
> > in wayland-scanner. It never occurred to me that people would be
> > shipping the generated files. You don't put them into VCS either, and
> > Weston takes care to not ship them.
> >  
> There's a couple of ideas which come to mind, why Weston does not ship
> the files:
>  - Thinko ? Similar to how the interface symbols are _explicitly_
> exported while devs lean that each project should have them
> statically.

Partly, perhaps, due to the below.

>  - The API/ABI generated by wayland-scanner is intentionally meant to
> be fluid ? Seriously doubt this is the case.

https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Code-Generation

Things that wayland-scanner generates are explicitly not part of the
library provided ABI. They *are* part of the library API on the parts
that the library actually installs.

When libwayland is updated, we obviously need to keep existing binaries
working. That implies that code generated by old scanners need to keep
on working in binaries.

I do not think that building with a new scanner and then running
against an old libwayland has been considered a worthwhile use case. So
far at least I have always considered that libwayland and scanner
versions only need to keep existing binaries working.

Do distributions build packages against the latest library versions
even though they (want to) guarantee the packages working with older
libraries too?

If yes, I suppose that's the oversight at upstream.

> And yes this is one example/reason why we want the scanner to provide
> a consistent API/ABI/other. Unless the user explicitly opts out.

I'm looking forward to proposals for that, I think for the development
cycle that starts in Feb, because I this is probably something we
should land early in the cycle.

It is also the reason I pointed you to the patch that deprecates
*_add_listener() and renames it to *_set_listener(), since that would
be a complex use case touching everything: libwayland API and ABI, and
scanner.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161205/2da3c7a0/attachment.sig>