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

[Andrew Kosteltsev]

Hi guys,

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:

1) scanner built by cross compiler and has original name (wayland-scanner)
2) scanner built by BUILD_CC and has complex name, for example,
arm-xxx-linux-gnueabihf-wayland-scanner (this scanner can be in the non
install binaries list)

That is all.

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.

I think it is not too complex but allows to build sources in one stage.

Best Regards,
Andrey K.


On Mon, Dec 5, 2016 at 1:01 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161205/afc75293/attachment.html>