[vlc-devel] [vlc-commits] contrib: lua: don´t mix native and cross compiled objects

[Rémi Denis-Courmont]

Le lauantaina 6. elokuuta 2016, 13.35.17 EEST Jean-Baptiste Kempf a écrit :
> On 06 Aug, Rémi Denis-Courmont wrote :
> > vlc | branch: master | Rémi Denis-Courmont <remi at remlab.net> | Sat Aug  6
> > 09:58:36 2016 +0300| [bdae0096827e2bebdc52ad883f37e1c3b431c926] |
> > committer: Rémi Denis-Courmont
> > 
> > contrib: lua: don´t mix native and cross compiled objects
> 
> This breaks cross-compiling for numerous targets.

As a matter of facts, in sequence, it actually does not break them. Removal of 
contrib from PATH "breaks" them.

This patch does three things:
- Don´t clobber the contrib target bin/ directory with a luac binary from 
wrong architecture.
- Don´t clean Lua in build process, do not interfere with the dependency 
propagation logic of contrib (which was the main point of rewriting it).
- Not run the cross-AR in place of native AR on a native static library.

I´m not even sure how this could have worked in light of the third item.


As for the PATH removal patch, contrib is not meant to build cross compilation 
tools at this point. That was very much a non-goal when it was designed, as it 
was when I redesigned it. In particular, contrib bin/ was never intended to be 
imported to PATH on the build machine and to contain build-time executables.

contrib bin has always contained target executables; you can use them if you 
build natively (e.g. gettext on MacOS) or if you copy them to the target (e.g. 
x265) manually.

> Case in point, my patches were reverted, because of this lua-32bits
> headers issue, and there was a LOT of discussion

Maybe; I don´t recall the patch in question.

> So:
> - either we stop the check that requires that luac must be give 32bits
>   output,

Well, I assume you mean to remove the requirement. Removing rafaël's check 
alone makes no sense. It is but a a sanity check. Without it you would get a 
run-time failure instead of a build failure.

>   and   the luac files will be different depending on the build
>   architecture (build on linux64 -> luac64 files)

I don´t really care. The 32-bits thing solved a real problem when it was 
introduced, but the world has changed between then and now.

However I am not sure how that´s supposed to work, unless we assume the build 
and host not only have the same endianess (as of now) but also the same bits 
width.

> - either you suggest a different solution for this issue

You can:
- build natively,
- do what you suggested above,
- use Rafaël' s extras/tools (add luac if not already there),
- extend contrib to generate cross-tools correctly
   (e.g. contrib/bin/${triplet}-luac
    as opposed to contrib/${triplet}/bin/luac), and
   use AC_CHECK_TOOL(S), or
- build your own binary anywhere else.

Lua does not seem to support building from subdirectory. So in any case, it 
presumably involves a separate copy of Lua source.

-- 
Rémi Denis-Courmont
http://www.remlab.net/