<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 4, 2015 at 11:12 AM, Élie Roux <span dir="ltr"><<a href="mailto:elie.roux@telecom-bretagne.eu" target="_blank">elie.roux@telecom-bretagne.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> The swiglib project<br>
> <a href="http://swiglib.foundry.supelec.fr" target="_blank">swiglib.foundry.supelec.fr</a> <<a href="http://swiglib.foundry.supelec.fr" target="_blank">http://swiglib.foundry.supelec.fr</a>><br>
<span>> tries to address these problems.<br>
> My current opinion is to avoid to include dynamic shared object (ie<br>
> so/dll files) in TeXLive<br>
> and  set  a path inside the TDS .<br>
<br>
</span>Why not, but this means that if some documents rely on external<br>
libraries, users won't be able to compile them, especially under Windows<br>
where it requires very advanced knowledge to compile anything. So this<br>
means that LuaTeX will never be able to use harfbuzz, etc.  This means<br>
that if someone wants to experiment on harfbuzz (change harfbuzz for<br>
anything here) will have to fork LuaTeX, statically compile harfbuzz<br>
against it, and distribute "luatex-harfbuzz", same for all other useful<br>
libraries...<br>
<span><br></span></blockquote><div><br></div><div>Why ?</div><div>Just provide a dso of a binding of harfbuzz, put it into the right TDS directory and load it with luatex.</div><div>The points are: 1) who does provide these dso ? 2) how to load it ? </div><div>With swiglib I provide some  dso, and I have shown how to load it in luatex. </div><div>ConTeXt has his own loader (much better than mine), LaTeX can have another one.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> ConTeXt already has a mechanism to load dso<br>
> (see 3.1 Application module location in the TDS<br>
> <a href="https://swiglib.foundry.supelec.fr/tb112/tb112scarso.html" target="_blank">https://swiglib.foundry.supelec.fr/tb112/tb112scarso.html</a>)<br>
> and it works quite well.<br>
<br>
</span>Loading dynamic libraries is currently quite easy indeed.<br>
<span><br>
> A command line switches as  --disable-write18  and --shell-restricted<br>
> currently are not implemented<br>
> but could be in the future (luajittex is more problematic),<br>
<br>
</span>That would be helpful... But I suppose that mean that you'll have to<br>
link against -ltexlua (name to be defined) instead of -llua52, because<br>
linking against -llua52 will never provide kpse-restricted funtions<br>
right? That sounds reasonable...<br>
<span><br></span></blockquote><div>This is true for windows, and in fact currently the TL luatex.exe  dll have different names</div><div>respect to the w32tex, something I hope to fix soon.</div><div>Only the luatex headers are mandatory</div><div>(under windows, symbols must be  resolved at compile time; under linux at runtime).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> if we keep the modules outside the TeXLive<br>
<br>
</span>Does it mean ConTeXt users will have all the nice swig modules, while<br>
TeXLive users won't? Seems a bit unfair... This also means that TeXLive<br>
will have a reduced ConTeXt?<br>
<span><br></span></blockquote><div>no, swiglib dso are a luatex thing only (and strictly coupled with the C headers of the lib, so in almost all case a lua/tex layer is advisable) </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> then they are optionals --- i.e. the user chooses to install them ---<br>
> and the developer has the responsibility to fix the problems.<br>
<br>
</span>But this also means that the average user can't install them (installing<br>
such a thing under Windows is way beyond average Windows user's<br>
ability). Even distributing shared libaries for LuaTeX through luarocks<br>
and asking users to install them is, I believe, confusing for the<br>
average user...<br>
<br></blockquote><div>yes, but it's easy to write a luatex script for downloading and installing a dso in the correct place.</div><div>(ConTeXt has not this script because we are discussing how to  integrate them into the context garden, but in principle is easy, so it has low priority).</div></div><div><br></div><div>A dso very likely could not be provide for all the platforms supported by TeXLive: </div><div>this means that a tex code that for example runs in Linux could not run in  Windows </div><div>or it could run and give different results.</div><div>This led to consequence that the same could have different result with the same TL on different platforms</div><div>(for example swiglib have no dso for Mac, and only one for FreeBSD, so these users already have very different results if they run a tex code that uses a dso )<br></div><div>Of course a dso often need to be in sync with the updates of the lib, so this led to management of the versions for the same TL and for different TL.</div><div><br></div><div>For these reasons I consider a dso  as an add-on under the control of the user, not something that TL should care.</div><div><br></div><div><br></div><div><br></div>-- <br><div>luigi<br></div>
</div></div>