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