[tex-live] [luatex] lltxplatform integration
luigi.scarso at gmail.com
Thu Jun 4 12:49:48 CEST 2015
On Thu, Jun 4, 2015 at 11:12 AM, Élie Roux <elie.roux at telecom-bretagne.eu>
> > 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
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
ConTeXt has his own loader (much better than mine), LaTeX can have another
> > 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
> 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
A dso very likely could not be provide for all the platforms supported by
this means that a tex code that for example runs in Linux could not run in
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tex-live