Re: Create cross wayland-scanner for toolchain or cross-development environment
I think now the simplest way to fix cross-builder's problem is that: When the USE_HOST_SCANNER variable is set we have to allow to redefine wayland_scanner variable in the same way as CC or CC_FOR_BUILD. For example by command line arguments: WAYLAND_SCANNER_FOR_BUILD=/usr/bin/wayland-scanner *./configure* --prefix=/usr --use-host-scanner=yes or WAYLAND_SCANNER=/usr/bin/wayland-scanner *./configure* --prefix=/usr --use-host-scanner=yes In this case we can avoid building errors (without patching) related to using scanner built (right now) for target machine on the development host. Best Regards, Andrey K. On Tue, Dec 6, 2016 at 6:18 PM, Emil Velikov wrote: > Yes I fully agree that things are not perfect atm, and we want to work > towards improving things. > I'll see to "polishing" the scanner as early as possible. > > Thanks > Emil > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
Yes I fully agree that things are not perfect atm, and we want to work towards improving things. I'll see to "polishing" the scanner as early as possible. Thanks Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
Ok. At least I can use USE_HOST_SCANNER variable or continue to patch Wayland Makefiles. That is not a problem for me. Best Regards, Andrey K. On Mon, Dec 5, 2016 at 3:23 PM, Pekka Paalanen wrote: > On Mon, 5 Dec 2016 14:13:23 +0300 > Andrew Kosteltsev wrote: > > > 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: > > Sorry, indeed, this thread was hijacked for the versioning discussion, > because it really matters which version of the scanner you happen to > use. > > > 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. > > Right, but your patch seems to add quite a lot of open-coded stuff that > should come from automake internals, IMO. Personally I would not be too > comfortable landing that - it is complicated code that bypasses > automake somewhat. It looks like it will always build the scanner twice > even for native builds, and I think it also breaks the "host scanner" > option. > > OTOH, you currently can (right?) build Wayland twice out-of-tree, first > configured for the build, the second configured for the host. It uses > the same common automake build code that is always used. You always > have at least some step for making the build scanner available. Anyway, > all that you write up in some meta-build system once, so the saved > effort is minimal. > > There's some movement towards Meson, which would also solve the > cross-build issue. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
On Mon, 5 Dec 2016 14:13:23 +0300 Andrew Kosteltsev wrote: > 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: Sorry, indeed, this thread was hijacked for the versioning discussion, because it really matters which version of the scanner you happen to use. > 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. Right, but your patch seems to add quite a lot of open-coded stuff that should come from automake internals, IMO. Personally I would not be too comfortable landing that - it is complicated code that bypasses automake somewhat. It looks like it will always build the scanner twice even for native builds, and I think it also breaks the "host scanner" option. OTOH, you currently can (right?) build Wayland twice out-of-tree, first configured for the build, the second configured for the host. It uses the same common automake build code that is always used. You always have at least some step for making the build scanner available. Anyway, all that you write up in some meta-build system once, so the saved effort is minimal. There's some movement towards Meson, which would also solve the cross-build issue. Thanks, pq pgpWrA1v3XzKu.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
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 wrote: > On Fri, 2 Dec 2016 17:06:29 + > Emil Velikov wrote: > > > On 2 December 2016 at 14:55, Pekka Paalanen wrote: > > > On Fri, 8 Jul 2016 11:29:16 +0100 > > > Emil Velikov wrote: > > > > > >> Hi all, > > >> > > >> Jumping the gun a bit, hope you'll forgive me :-) > > >> > > >> On 8 July 2016 at 09:17, Quentin Glidic 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 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
On Fri, 2 Dec 2016 17:06:29 + Emil Velikov wrote: > On 2 December 2016 at 14:55, Pekka Paalanen wrote: > > On Fri, 8 Jul 2016 11:29:16 +0100 > > Emil Velikov wrote: > > > >> Hi all, > >> > >> Jumping the gun a bit, hope you'll forgive me :-) > >> > >> On 8 July 2016 at 09:17, Quentin Glidic > >> 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 pgp9lruPdW7mi.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
On 2 December 2016 at 14:55, Pekka Paalanen wrote: > On Fri, 8 Jul 2016 11:29:16 +0100 > Emil Velikov wrote: > >> Hi all, >> >> Jumping the gun a bit, hope you'll forgive me :-) >> >> On 8 July 2016 at 09:17, Quentin Glidic >> 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. > 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. - The API/ABI generated by wayland-scanner is intentionally meant to be fluid ? Seriously doubt this is the case. 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. Thanks Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
On Fri, 8 Jul 2016 11:24:15 +0200 Quentin Glidic wrote: > On 08/07/2016 10:46, Andrew Kosteltsev wrote: > > Hi Quentin. > > > > I see. My suggestion related to simplify the build process on developer > > machines which doesn't have pre-installed native Wayland package. And > > also I think it would be good if wailand-scanner output will be > > generated by scanner which has the same version as target machine scanner. Hi, I think this has usually been solved by building wayland manually twice: first only the scanner for the build arch, second the full build for the target machine. > > Currently developers must have installed wayland package and it is not > > convenient if developer builds several targets for different CPU (and > > may be different versions of some SW packages) at the same time using > > cross environment. > > > > (for example, GNU file also requires native file utility on developer > > machine, moreover it must have same version). I think not all needed > > tools can be implemented into toolchain like cross-compiler. Some of > > them can be built and added into DevEnv later on build time. > > > > Any way It is up to you. I just suggest. > > > I see your concern, and you should worry about only one thing: that your > native libwayland package (so your wayland-scanner) is newer than the > one you build. > libwayland, and thus the scanner, will remain backward-compatible, so > there is no harm in generating an old libwayland with a newer scanner. > At least until wayland 2.0. :-) Actually wayland-scanner will use all new features it knows about, which means libwayland must be equal or later than the scanner. This was especially obvious when the scanner started using new libwayland ABI. We only guarantee that upgrading libwayland will not break existing binaries (or builds), which means that old scanner will always work with a new libwayland. Thanks, pq pgpSyFFKkuPE4.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
On Fri, 8 Jul 2016 11:29:16 +0100 Emil Velikov wrote: > Hi all, > > Jumping the gun a bit, hope you'll forgive me :-) > > On 8 July 2016 at 09:17, Quentin Glidic > 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? 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. Thanks, pq pgpTeOuadAmM2.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
Hi Quentin. I see. My suggestion related to simplify the build process on developer machines which doesn't have pre-installed native Wayland package. And also I think it would be good if wailand-scanner output will be generated by scanner which has the same version as target machine scanner. Currently developers must have installed wayland package and it is not convenient if developer builds several targets for different CPU (and may be different versions of some SW packages) at the same time using cross environment. (for example, GNU file also requires native file utility on developer machine, moreover it must have same version). I think not all needed tools can be implemented into toolchain like cross-compiler. Some of them can be built and added into DevEnv later on build time. Any way It is up to you. I just suggest. Best Regards, Andrey K. On Fri, Jul 8, 2016 at 11:17 AM, Quentin Glidic < sardemff7+wayl...@sardemff7.net> wrote: > On 18/05/2016 14:55, Andrew Kosteltsev wrote: > >> Hi guys, >> >> Currently during cross compilation of the wayland library the >> wayland-scanner utility is built by cross-gcc and then used on the >> developer machine which lead build error. >> >> I suggest to build development version, for example, >> $(top_builddir)/build-wayland-scanner and to use this utility during >> cross-buildin the wayland package. >> >> When build is done the user can copy this release of scanner utility >> into his toolchain or into his SDK for example wit $(host-triplet) preffix >> >> cp $(top_builddir)/build-wayland-scanner >> SDK/bin/$(host_triplet)-wayland-scanner >> >> 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 >> >> I have attached the patch for you. Please look at this patch and please >> make decision related to cross building the wayland. >> >> Of course after applying attached patch we have to reconfigure src >> package; >> >> $ autoreconf -i >> > > NAK from me on this patch. > > wayland-scanner does not output host-specific code, so you should simply > use the one in the PATH of your build machine, via --with-host-scanner. > > Cheers, > > -- > > Quentin “Sardem FF7” Glidic > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
Of course, not an old lib with a never scanner! only the same. On Fri, Jul 8, 2016 at 12:24 PM, Quentin Glidic < sardemff7+wayl...@sardemff7.net> wrote: > On 08/07/2016 10:46, Andrew Kosteltsev wrote: > >> Hi Quentin. >> >> I see. My suggestion related to simplify the build process on developer >> machines which doesn't have pre-installed native Wayland package. And >> also I think it would be good if wailand-scanner output will be >> generated by scanner which has the same version as target machine scanner. >> > > > >> Currently developers must have installed wayland package and it is not >> convenient if developer builds several targets for different CPU (and >> may be different versions of some SW packages) at the same time using >> cross environment. >> >> (for example, GNU file also requires native file utility on developer >> machine, moreover it must have same version). I think not all needed >> tools can be implemented into toolchain like cross-compiler. Some of >> them can be built and added into DevEnv later on build time. >> >> Any way It is up to you. I just suggest. >> > > > I see your concern, and you should worry about only one thing: that your > native libwayland package (so your wayland-scanner) is newer than the one > you build. > libwayland, and thus the scanner, will remain backward-compatible, so > there is no harm in generating an old libwayland with a newer scanner. > At least until wayland 2.0. :-) > > > Cheers, > > -- > > Quentin “Sardem FF7” Glidic > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
Hi Emil, Unfortunattely Mesa-11.2.2 still requires wayland-scanner. But I will check it again. Best Regards, Andrey K. 8 июля 2016 г. 13:29 пользователь "Emil Velikov" написал: Hi all, Jumping the gun a bit, hope you'll forgive me :-) On 8 July 2016 at 09:17, Quentin Glidic 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. -Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
Hi all, Jumping the gun a bit, hope you'll forgive me :-) On 8 July 2016 at 09:17, Quentin Glidic 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. -Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
On 08/07/2016 10:46, Andrew Kosteltsev wrote: Hi Quentin. I see. My suggestion related to simplify the build process on developer machines which doesn't have pre-installed native Wayland package. And also I think it would be good if wailand-scanner output will be generated by scanner which has the same version as target machine scanner. > Currently developers must have installed wayland package and it is not convenient if developer builds several targets for different CPU (and may be different versions of some SW packages) at the same time using cross environment. (for example, GNU file also requires native file utility on developer machine, moreover it must have same version). I think not all needed tools can be implemented into toolchain like cross-compiler. Some of them can be built and added into DevEnv later on build time. Any way It is up to you. I just suggest. I see your concern, and you should worry about only one thing: that your native libwayland package (so your wayland-scanner) is newer than the one you build. libwayland, and thus the scanner, will remain backward-compatible, so there is no harm in generating an old libwayland with a newer scanner. At least until wayland 2.0. :-) Cheers, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Create cross wayland-scanner for toolchain or cross-development environment
On 18/05/2016 14:55, Andrew Kosteltsev wrote: Hi guys, Currently during cross compilation of the wayland library the wayland-scanner utility is built by cross-gcc and then used on the developer machine which lead build error. I suggest to build development version, for example, $(top_builddir)/build-wayland-scanner and to use this utility during cross-buildin the wayland package. When build is done the user can copy this release of scanner utility into his toolchain or into his SDK for example wit $(host-triplet) preffix cp $(top_builddir)/build-wayland-scanner SDK/bin/$(host_triplet)-wayland-scanner 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 I have attached the patch for you. Please look at this patch and please make decision related to cross building the wayland. Of course after applying attached patch we have to reconfigure src package; $ autoreconf -i NAK from me on this patch. wayland-scanner does not output host-specific code, so you should simply use the one in the PATH of your build machine, via --with-host-scanner. Cheers, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Create cross wayland-scanner for toolchain or cross-development environment
Hi guys,
Currently during cross compilation of the wayland library the
wayland-scanner utility is built by cross-gcc and then used on the
developer machine which lead build error.
I suggest to build development version, for example,
$(top_builddir)/build-wayland-scanner and to use this utility during
cross-buildin the wayland package.
When build is done the user can copy this release of scanner utility into
his toolchain or into his SDK for example wit $(host-triplet) preffix
cp $(top_builddir)/build-wayland-scanner
SDK/bin/$(host_triplet)-wayland-scanner
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
I have attached the patch for you. Please look at this patch and please
make decision related to cross building the wayland.
Of course after applying attached patch we have to reconfigure src package;
$ autoreconf -i
Best Regards,
Andrey K.
diff -b --unified -Nr wayland-1.10.0-orig/Makefile.am wayland-1.10.0/Makefile.am
--- wayland-1.10.0-orig/Makefile.am 2015-11-23 23:06:44.0 +0300
+++ wayland-1.10.0/Makefile.am 2016-05-18 15:15:08.399576274 +0300
@@ -2,6 +2,10 @@
SUBDIRS = doc
endif
+CC_FOR_BUILD = gcc
+LD_FOR_BUILD = $(CC_FOR_BUILD)
+COMPILE_FOR_BUILD = $(CC_FOR_BUILD)
+
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
AM_CPPFLAGS = \
@@ -33,7 +37,7 @@
if USE_HOST_SCANNER
wayland_scanner = wayland-scanner
else
-$(BUILT_SOURCES) : wayland-scanner
+$(BUILT_SOURCES) : wayland-scanner build-wayland-scanner
wayland_scanner = $(top_builddir)/wayland-scanner
endif
@@ -93,20 +97,44 @@
pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc
+build-wayland-util.c: $(top_srcdir)/src/wayland-util.c
+ cp $< $@
+
+build-scanner.c: $(top_srcdir)/src/scanner.c
+ cp $< $@
+
+build-dtddata.S: $(top_srcdir)/src/dtddata.S
+ cp $< $@
+
+build_wayland_scanner = $(top_builddir)/build-wayland-scanner
+build_wayland_scanner_SOURCES = build-scanner.c build-wayland-util.c build-dtddata.S
+build_wayland_scanner_LDADD = -lexpat -lxml2
+build_wayland_scanner_LINK = $(LD_FOR_BUILD) -o $@
+
+build-%.o : build-%.c
+ $(AM_V_CC)$(COMPILE_FOR_BUILD) -I$(top_srcdir)/src -I/usr/include/libxml2 -MT $@ -MD -MP -MF $(DEPDIR)/build-$*.Tpo -c -o $@ $<
+ $(AM_V_at)$(am__mv) $(DEPDIR)/build-$*.Tpo $(DEPDIR)/build-$*.Po
+
+build-%.o : build-%.S
+ $(AM_V_CPPAS)depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
+ $(AM_V_CPPAS)$(COMPILE_FOR_BUILD) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
+ $(am__mv) $$depbase.Tpo $$depbase.Po
+
+
protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
- $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@
+ $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(build_wayland_scanner) code < $< > $@
protocol/%-server-protocol.h : $(top_srcdir)/protocol/%.xml
- $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header < $< > $@
+ $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(build_wayland_scanner) server-header < $< > $@
protocol/%-client-protocol.h : $(top_srcdir)/protocol/%.xml
- $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header < $< > $@
+ $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(build_wayland_scanner) client-header < $< > $@
protocol/%-server-protocol-core.h : $(top_srcdir)/protocol/%.xml
- $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header -c < $< > $@
+ $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(build_wayland_scanner) server-header -c < $< > $@
protocol/%-client-protocol-core.h : $(top_srcdir)/protocol/%.xml
- $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header -c < $< > $@
+ $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(build_wayland_scanner) client-header -c < $< > $@
BUILT_SOURCES = \
$(nodist_libwayland_server_la_SOURCES) \
@@ -168,7 +196,7 @@
exec-fd-leak-checker
noinst_PROGRAMS =\
- fixed-benchmark
+ fixed-benchmark build-wayland-scanner
check_LTLIBRARIES = libtest-runner.la
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
