[DVIPDFMx] 2010 engine plan

[Taco Hoekwater]

Karl Berry wrote:
>     though it is still api-compatible, it is 100% implementation
>     compatible with stock lua.
> 
> I assume you mean it is *not* 100% implementation compatible.

Yes, that is what I meant.

>     this will only work for as long as luatex's lua api really is
>     100% compatible with the stock lua 5.1 dll
> 
> Isn't that a highly desirable state of affairs?  It seems to me that it
> would be very nice for users to be able to take Lua .dll's from wherever
> and just be able to drop them in place and use them with LuaTeX.

Of course I agree with that, but I have not enough knowledge of
windows to know how safe this approach is. Hans and I tried a
couple of these external dlls and some work, while others don't,
but we cannot really say why.

It does seem that gui toolkit modules cause trouble (probably because
of threading safety rules or exception handling in the toolkit itself)
but I think we can live with that.

> One concern that comes to my mind with us providing something named
> lua51.dll (whether it's the real one or just a redirection) is the
> creation of a conflict/confusion with the original Lua.  I know it can
> be resolved technically through search paths, but ...  is this a normal
> thing to do on Windows?

This is (was?) fairly normal. Not encouraged, but not very odd either.

>     There is just one small problematic thing and that is that -Wl,-E is
>     a bit too wild: it exports a great many more symbols than just the ones
>     from the lua api. This is fixable (at least for gcc) 
> 
> Browsing through the GNU ld documentation, is the "fixable" you mean
> using --dynamic-list?  I can easily see that turning into a big pain at
> many levels.

I was thinking of compiling everything with --fvisibility=hidden except
for the lua51 subdir. That is wat Luigi Scarso worked out for his
lunatic luatex extension, and it seems that works fairly well. But
it does introduce an extra complication in the build scripts, and
I do not know how that would combine with the --with-system-zlib etc.

> Is there a practical problem with exporting everything?  If not, I'd be
> inclined to let it go wild ...

One thing Luigi figured out is that with the -E, it will be problematic
(I think he said it was even impossible) to load external lua dlls that
use the static libraries in libs/ like libpng, libz etc. unless luatex
itself also is compiled with the --system- versions of those. But other
than that, -E works fine, afaik.

Conclusion: perhaps we should wait and see what happens for this TL
release, and if there are actual real-life problems try to come up with
a better solution next year.


Best wishes,
Taco