<div dir="ltr">Ok.<div><br></div><div>At least I can use USE_HOST_SCANNER variable or continue to patch Wayland Makefiles. That is not a problem for me.<br></div><div><br></div><div>Best Regards,</div><div>Andrey K.</div><div><br></div><div>  </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 5, 2016 at 3:23 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 Mon, 5 Dec 2016 14:13:23 +0300<br>
Andrew Kosteltsev <<a href="mailto:kosteltsev@gmail.com">kosteltsev@gmail.com</a>> wrote:<br>
<br>
> Hi guys,<br>
><br>
> This is no versioning question. I think when the host,target is not equal<br>
> to build (I mean configure options --build,--taget,--host) we can compile<br>
> two scanners:<br>
<br>
</span>Sorry, indeed, this thread was hijacked for the versioning discussion,<br>
because it really matters which version of the scanner you happen to<br>
use.<br>
<span class=""><br>
> 1) scanner built by cross compiler and has original name (wayland-scanner)<br>
> 2) scanner built by BUILD_CC and has complex name, for example,<br>
> arm-xxx-linux-gnueabihf-<wbr>wayland-scanner (this scanner can be in the non<br>
> install binaries list)<br>
><br>
> That is all.<br>
><br>
> In this case the engineer who prepare the package can make decision about<br>
> installation the second scanner into his development environment (in the<br>
> same way as cross-compiler in his toolchain) to be able using this<br>
> build-machine scanner for build other packages for the same target machine.<br>
><br>
> I think it is not too complex but allows to build sources in one stage.<br>
<br>
</span>Right, but your patch seems to add quite a lot of open-coded stuff that<br>
should come from automake internals, IMO. Personally I would not be too<br>
comfortable landing that - it is complicated code that bypasses<br>
automake somewhat. It looks like it will always build the scanner twice<br>
even for native builds, and I think it also breaks the "host scanner"<br>
option.<br>
<br>
OTOH, you currently can (right?) build Wayland twice out-of-tree, first<br>
configured for the build, the second configured for the host. It uses<br>
the same common automake build code that is always used. You always<br>
have at least some step for making the build scanner available. Anyway,<br>
all that you write up in some meta-build system once, so the saved<br>
effort is minimal.<br>
<br>
There's some movement towards Meson, which would also solve the<br>
cross-build issue.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div>