Hans van der Meer wrote:
Taco: XCFLAGS seems indeed to be added later on the gcc line than the default compile flags, so it works. It would be nice however, if you could at any one moment cleanup this thing. Allthough I can only guess how very very busy you are!
As long as it still works for me, build issues will be way at the bottom of my todo list: I don't understand (nor like) much of autofoo, so I am lacking in the motivation department as well as in the time schedule. Meanwhile, if you (or anyone else) has the time, knowledge and motivation to help with this kind of thing, I am more-than-willing to apply patches :-) Best wishes, Taco
On Fr, 21 Mär 2008, Taco Hoekwater wrote:
Meanwhile, if you (or anyone else) has the time, knowledge and motivation to help with this kind of thing, I am more-than-willing to apply patches :-)
I guess we have to get this at least more or less working for the
inclusing into TeX Live ... btw, any timeline anyone?
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
On Fr, 21 Mär 2008, Martin Schröder wrote:
I'll try it on Sunday. :-)
Good, I will leave on sunday for 3 week ;-) See you at Bachotek!
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
2008/3/23, Martin Schröder
TL is currently broken because of the new TeX and aleph & omega & xetex, so I'm stuck. :-(
r7124 has a first import, but compilation is disabled (to enable it, remove the string #LUATEX from web2c/Makefile.in). I've stopped because Taco changed the signature of convert from 3 parameters to 4 and I don't want to introduce that change to web2c; I leave that to Karl (and Taco is offline). If enabled compilation currently fails when converting luatangle: srcdir=../../../texk/web2c /bin/sh ../../../texk/web2c/web2c/convert luatangle syntax error: Last token = 290 ("), error buffer = `LUATANGLEHELP', last id = `LUATANGLEHELP' (not in symbol table). ../../../texk/web2c/web2c/convert: conversion of luatangle.p failed, moving dregs: ../../../texk/web2c/web2c/convert: mv luatangle.c luatangle.h /tmp make[2]: *** [luatangle.c] Error 1 make[2]: Leaving directory `/home/ms/tex/texlive/svn/trunk/Build/source/Work/texk/web2c' make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/ms/tex/texlive/svn/trunk/Build/source/Work/texk' make: *** [all] Error 1 Even if building of luatex will succeed once, we still need additional work: - the top-level configure needs a --without-luatex switch - the libs probably need some configure work - and Taco has spent quite some time in making cross-compilation of luatex work. The changes for that might clash with the TL "framework" Best Martin
Martin Schröder wrote:
2008/3/23, Martin Schröder
: TL is currently broken because of the new TeX and aleph & omega & xetex, so I'm stuck. :-(
r7124 has a first import, but compilation is disabled (to enable it, remove the string #LUATEX from web2c/Makefile.in). I've stopped because Taco changed the signature of convert from 3 parameters to 4 and I don't want to introduce that change to web2c; I leave that to Karl (and Taco is offline). If enabled compilation currently fails when converting luatangle:
srcdir=../../../texk/web2c /bin/sh ../../../texk/web2c/web2c/convert luatangle syntax error: Last token = 290 ("), error buffer = `LUATANGLEHELP', last id = `LUATANGLEHELP' (not in symbol table). .../../../texk/web2c/web2c/convert: conversion of luatangle.p failed, moving dregs: .../../../texk/web2c/web2c/convert: mv luatangle.c luatangle.h /tmp make[2]: *** [luatangle.c] Error 1 make[2]: Leaving directory `/home/ms/tex/texlive/svn/trunk/Build/source/Work/texk/web2c' make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/ms/tex/texlive/svn/trunk/Build/source/Work/texk' make: *** [all] Error 1
Even if building of luatex will succeed once, we still need additional work: - the top-level configure needs a --without-luatex switch - the libs probably need some configure work - and Taco has spent quite some time in making cross-compilation of luatex work. The changes for that might clash with the TL "framework"
we're not going to cripple the compilation by the existing complexity of the tex source tree, are we; i'm somewhat jalous of those repositories with clean source trees that one can download and compile on all relevant platforms without trouble one reason for the separate luatex/mplib tree was that it gives us the possibility to stepwise only add modern progs that we need and thereby simplify things one thing that really bothers me is that tex and friends, being just data proessors (not much gui mes sinvolved), have such a huge and complex source tree Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
we're not going to cripple the compilation by the existing complexity of No one is talking about "crippling" anything. with clean source trees that one can download and compile on all relevant platforms without trouble If you're talking about Windows, I don't believe Akira makes many changes to the sources. But I've never actually looked at his tree. I know he does not use configure at all (of course). On every other platform, it already does build out of the box so far as I know. One of my hopes is that we will be able to adapt Taco's cross compiling so that we can build all the Windows binaries that way. Jonathan is looking towards that for his new front-end. If all you wanted to compile was tex and mf and use it on one system and have no add-on macros, sure, it would be simple. Obviously we are very far from that. one thing that really bothers me is that tex and friends, being just data proessors (not much gui mes sinvolved), There are GUI programs in TL of several varieties (xdvi, info), although I don't think they add much to the perceived complexity. have such a huge and complex source tree Given the constraints of operating from a language that was dead for systems programming in 1980, a software engineering methodology that forbids us from modifying the original source (tex.web), a bewildering array of programs and authors each of whom likes to do things in their own way (web vs. cweb vs. (c)tie vs. C vs. C++ vs. shell scripts vs. Lua vs. ...), and almost none of whom have any interest in configuration issues, I'd say it's more amazing that it builds on every known platform with, really, minimal trouble for people. If you have any practical suggestions for how to make the build simpler, believe me, I'd love to hear it. TL is pretty much unique in the free software world, in that we provide precompiled and relocatable binaries and a runnable tree of thousands upon thousands of files for N platforms. You can't expect it all to come for free. And you can't just wave your hands and say we don't need it. Sorry, but when I hear about how horrible the TeX sources are, I get to feeling a bit defensive! karl
Karl Berry wrote:
On every other platform, it already does build out of the box so far as I know. One of my hopes is that we will be able to adapt Taco's cross compiling so that we can build all the Windows binaries that way. Jonathan is looking towards that for his new front-end.
that would be great indeed
Given the constraints of operating from a language that was dead for systems programming in 1980, a software engineering methodology that forbids us from modifying the original source (tex.web), a bewildering array of programs and authors each of whom likes to do things in their own way (web vs. cweb vs. (c)tie vs. C vs. C++ vs. shell scripts vs. Lua vs. ...), and almost none of whom have any interest in configuration issues, I'd say it's more amazing that it builds on every known platform with, really, minimal trouble for people.
sure, i understand that ... one of the thing is hope for is that eventually we will have everything in portable c
If you have any practical suggestions for how to make the build simpler, believe me, I'd love to hear it. TL is pretty much unique in the free software world, in that we provide precompiled and relocatable binaries and a runnable tree of thousands upon thousands of files for N platforms. You can't expect it all to come for free. And you can't just wave your hands and say we don't need it.
sure, but what always puzzled me is the close connection between a texmf tree and binaries; this may have changed now that we no longer have a dependency (i.e. no pool file any more)
Sorry, but when I hear about how horrible the TeX sources are, I get to feeling a bit defensive!
no problem; i'd not have mentioned it if i'd not knew you; its' just that i wonder what history we still carry that makes live problematic while maybe we can drop part of that history (say that all pascal sources are turned into c ... that would simplify things, wouldn't it?) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
sure, but what always puzzled me is the close connection between a texmf tree and binaries; The fmt files will still embed pool checksums (among other things) so can't be arbitrarily swapped around with different binaries. Other than that, I think it would basically work to use a binary from one release and a tree from another, not that I've ever tried it (or see much reason to). Obviously 99% of the macros are independent of the particular binary. this may have changed now that we no longer have a dependency (i.e. no pool file any more) Indeed, that is a good advance. while maybe we can drop part of that history (say that all pascal sources are turned into c ... that would simplify things, wouldn't it?) It sure would, but knuth's tex & mf, plus omega and aleph will never be converted. So as long as we distribute Knuth's tex ... BTW, do you think aleph can become a symlink to luatex?! karl
Karl Berry wrote:
BTW, do you think aleph can become a symlink to luatex?!
sure, aleph is no longer actively maintained it would be interesting to know if there are real omega users out there; it was never stable enough for production so ... Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
sure, aleph is no longer actively maintained I know it's not maintained, but that's a different question than are there any users who will be unhappy if it will get replaced by luatex. However, since it's all the same people :), if you tell me to get rid of it and just make it luatex, I will do so, with great pleasure. it would be interesting to know if there are real omega users out there; it was never stable enough for production so ... There are Omega users, although clearly not a lot. I see occasional questions and answers on the lists, even an article or two. I can't get rid of that one without opening a huge can of worms, so I'm not even going to try ... karl
because Taco changed the signature of convert from 3 parameters to 4 and I don't want to introduce that change to web2c; I leave that to Not a big deal. I will get to it the next time I have development minutes -- hopefully later today, else tomorrow morning, barring emergencies. Looking at the scripts, it might work to simply copy in the luatex convert and add " ." to the end of line 81 in texk/web2c/Makefile.in, ie, web2c = srcdir=$(srcdir) $(SHELL) $(srcdir)/web2c/convert . Of course we want to preserve the cross-compiling stuff Taco has done, which I guess for starters will mean adding native = @NATIVEWEB@ target = @TARGET@ host = @HOST@ from the luatex/.../web2c/Makefile.in and corresponding configure stuff. But just to keep going for a first native build, the above might do. - the top-level configure needs a --without-luatex switch Easy enough, of course. - the libs probably need some configure work No doubt. Whatever we have to do ... not like we have an option. k
I imported the luatex web2c/convert with the native tooldir first arg to TeX Live. Can you please try luatex again now and see if it gets any farther? (I am so far behind on other things I didn't try it.) I also declared loadpoolstrings in web2c/texmf.defines instead of having to redundantly repeat it in the five or so other .defines files. I trust that's ok; if problems, let me know. Thanks, k
participants (5)
-
Hans Hagen
-
karl@freefriends.org
-
Martin Schröder
-
Norbert Preining
-
Taco Hoekwater