[luatex] [tex-live] lltxplatform integration

[Élie Roux]

> The points are: 1) who does provide these dso ?

Precisely... I might misunderstood your point of view, but I though you
wanted no dso in TeXLive... which would mean that each package is
responsible for providing dso files, and then users would manually have
to go to like the github page of packages, and manually install or
compile them... Or maybe compiled binaries could be provided on CTAN...
I don't know... How do you see that part?

> 2) how to load it ? With swiglib I provide some  dso, and I have
> shown how to load it in luatex.

I don't think loading dso is really an issue here, it seems fairly easy,
the main questions are (I think):

- is dso loading allowed by default?
- are dso provided by TeXLive?

> 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).

I'm not entirely sure I understand... Can you give a short example of
how to compile a dynamic library against luatex (if possible under Linux)?

> For these reasons I consider a dso  as an add-on under the control
> of the user, not something that TL should care.

So your proposal is to have something like a package manager a la
luarocks, specific to LuaTeX, parallel to TeXLive, CTAN and MikTeX... I
admit this is quite counter-intuitive to me, and it seems to make
another layer in something already quite complex... But if it's the way
to go why not...

> 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).

I see...

> 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.

In some cases yes, but in others (such as harfbuzz) no, and in some
cases it will be intended (lualatex-platform will of course not read
Windows registry under Linux)... I don't see obvious cases where this
might be a problem...

> This led to consequence that the same could have different result
> with the same TL on different platforms

Theoretically yes, though this seems quite rare...

> (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 )

Part of why distributing things with TeXLive will bring much more
homogeneity...

> 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.

This smells like headaches... Especially if MikTeX doesn't follow
TeXLive precisely, this could mean that the package manager would have
to provide binaries for:
- different versions of the packages themselves
- different platforms
- different versions of LuaTeX
- possibly different versions of the distribution (ConTeXtgarden,
TeXLive, MikTeX)
- possiblty different versions of the package manager itself

I wish good luck to someone wanting to maintain that! Having the
binaries in TeXLive is more statical, but seems way more simple... at
least if this package manager is supposed to be shared by the different
formats... But maybe you meant that ConTeXt would have its package
manager and its compiled package database, "LaTeX" (whatever that means)
or TeXLive would have another one, etc.?

Thanks a lot!
-- 
Elie