Thanks for the explanations, Rémi.<div><br></div><div>Like <span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;line-height:16px">Rafaël, I ran across this problem only when cross-compiling Win32 on a 64-bit machine.  </span><a href="http://wiki.videolan.org/Win32Compile_Under_Fedora#Install_32-bit_Lua">http://wiki.videolan.org/Win32Compile_Under_Fedora#Install_32-bit_Lua</a></div>
<div><br></div><div> </div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The playlist parsers are involved in many cases while probing<br>
> the input format. The SD plugins are all run when enumerating services.<br>
> Moreover it turns out that most of the Lua scripts belong in one of these<br>
> two categories.<br>
<br>
Still the additional CPU load is minimal.<br>
<br>
I was thinking of distributing lua files, and compiling them once per<br>
run then caching the bytecode, thus no .luac required.<br>
<br>
Or then again compile them at installation.<br>
<br>
No idea how hard are those 2 solutions<br>
<br></blockquote><div>That was pretty much exactly my thinking. If there's no interest in pursuing this line, however, I won't waste my time looking into it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

> You can download the original Lua files from vlc.git or from the tarballs<br>
> (and run them). I do not see any tremendousness here.<br>
<br>
It's not particularly difficult but having plain text files in our<br>
distributions is nicer, not to mention smaller to distribute.<br>
<br></blockquote><div>Seems to me you should always distribute the .lua files. Lua will always prefer the .luac files if they exist, and distributing the .lua files has the additional advantage of allowing people to delete the .luac files and have a functioning VLC if there is a cross-compile problem. Not to mention my previous comment about encouraging scripting knowledge.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">><br>
>> That micro optimization just makes packaging difficult,<br>
><br>
> It has been in previous releases, and it has not caused nay problems.<br>
<br>
Yeah I mostly discovered it because of win64 buildbot which is built on<br>
x86_64.<br>
It'll be a problem for people who build win32 on x86_64 (i.e. not our<br>
buildbot setup but might affect j-b when he makes a release binary)<br> </blockquote><div>Somebody is actually considering how it might affect J-B? </div><div>:-)</div><div><br></div><div><br></div></div></div>