From peb at mppmu.mpg.de Thu Jan 9 17:40:47 2003 From: peb at mppmu.mpg.de (Peter Breitenlohner) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.2 -- almost there II In-Reply-To: <87u1h4fyum.fsf@infovore.xs4all.nl> References: <877ke4jwlc.fsf_-_@infovore.xs4all.nl> <87u1h4fyum.fsf@infovore.xs4all.nl> Message-ID: On Mon, 23 Dec 2002, Olaf Weber wrote: > I've put web2c 7.4.2 sources up on tug.org in ~ftp/tex. Thus they'll > appear on CTAN in due course(?) Hi Olaf, when using a shared libkpathsea, it would be nice to know to what extent different versions are (backwards) compatible. The kpathsea library versions should then go with these (in-)compatibilities, and not as it seems to be at present: web2c-7.x.y <=> libkpathsea.so.3.x.y Do you have any info on this? Moreover, it would be nice to code the (in-)compatibilities into the soname (at least on platforms where this is apropriate). The soname should then be either libkpathsea.so.3, or libkpathsea.so.3.x, or even libkpathsea.so.3.x.y, depending how incompatible things are. (Remember, it is the soname codeded into the binary, that determines which library version among possibly different ones gets loaded at run time. After all that's one of the aspects where unix systems are definitely superior to MicroS$$t Windo$$ which -- as far as I know -- doesn't allow different versions of the same library to coexist.) regards Peter Breitenlohner From olaf at infovore.xs4all.nl Thu Jan 9 19:04:05 2003 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.2 -- almost there II In-Reply-To: References: <877ke4jwlc.fsf_-_@infovore.xs4all.nl> <87u1h4fyum.fsf@infovore.xs4all.nl> Message-ID: <87ptr6xkru.fsf@infovore.xs4all.nl> Peter Breitenlohner writes: > On Mon, 23 Dec 2002, Olaf Weber wrote: >> I've put web2c 7.4.2 sources up on tug.org in ~ftp/tex. Thus they'll >> appear on CTAN in due course(?) > Hi Olaf, Long time no hear. > when using a shared libkpathsea, it would be nice to know to what extent > different versions are (backwards) compatible. The kpathsea library versions > should then go with these (in-)compatibilities, and not as it seems to be at > present: > web2c-7.x.y <=> libkpathsea.so.3.x.y > Do you have any info on this? The kpathsea versions go in lockstep with the web2c versions because they are released in lockstep. That's the only, bad, reason. I'm trying to rework kpathsea, so that it can be sanely packaged separately, and then also be versioned in a saner manner. Part of the problem is that currently all kpathsea headers are exposed to applications compiling against kpathsea, which means that internal information is visible. One of the things I'm working on is to have a well-defined boundary, with the public interface in a few headers, and the private headers not visible at all. Right now, I give NO guarantees that something compiled against (say) kpathsea 3.4.1 will work with kpathsea 3.4.2. In practice, I believe that kpathsea 3.4.x is compatible with 3.4.y, and it is not impossible that 3.3.x is compatible with 3.3.y. > Moreover, it would be nice to code the (in-)compatibilities into the soname > (at least on platforms where this is apropriate). The soname should then be > either libkpathsea.so.3, or libkpathsea.so.3.x, or even > libkpathsea.so.3.x.y, depending how incompatible things are. That's a goal, but not the reality at present. -- Olaf Weber (This space left blank for technical reasons.) From peb at mppmu.mpg.de Thu Jan 9 19:29:18 2003 From: peb at mppmu.mpg.de (Peter Breitenlohner) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.2 -- almost there II In-Reply-To: <87ptr6xkru.fsf@infovore.xs4all.nl> References: <877ke4jwlc.fsf_-_@infovore.xs4all.nl> <87u1h4fyum.fsf@infovore.xs4all.nl> <87ptr6xkru.fsf@infovore.xs4all.nl> Message-ID: On Thu, 9 Jan 2003, Olaf Weber wrote: > Part of the problem is that currently all kpathsea headers are exposed > to applications compiling against kpathsea, which means that internal > information is visible. One of the things I'm working on is to have a > well-defined boundary, with the public interface in a few headers, and > the private headers not visible at all. That would be really good. That should also allow to compile individual programs against an installed version, e.g. 'configure --with-system-kpathsea', where autoconf should then test for a sufficiently recent version. > Right now, I give NO guarantees that something compiled against (say) > kpathsea 3.4.1 will work with kpathsea 3.4.2. In practice, I believe > that kpathsea 3.4.x is compatible with 3.4.y, and it is not impossible > that 3.3.x is compatible with 3.3.y. I see. I did notice a binary incompatibility between 3.3.8 (from xdvik-22.40s.tar.gz) and 3.4.2 from web2c-7.4.2. > > Moreover, it would be nice to code the (in-)compatibilities into the soname > > (at least on platforms where this is apropriate). The soname should then be > > either libkpathsea.so.3, or libkpathsea.so.3.x, or even > > libkpathsea.so.3.x.y, depending how incompatible things are. So at the moment the soname probably ought to be libkpathsea.so.3.x.y to be safe. That would at least allow programs built with different (shared) kpathsea versions to coexist (i.e., allow the libraries to coexist in the same directory). > That's a goal, but not the reality at present. Certainly, but rather easy to achieve. I use a simple patch to do that for linux-gnu, and I could look up libtool how this is done for other systems and copy that to klibtool. BTW: Some time ago you wrote that you intend to switch to libtool. Couldn't (shouldn't) one also switch to automake? And switch to a newer autoconf version, 2.13 is really ancient and I am surprised you still have that one around. What is the current status? If you wish I could try to help. regards Peter From olaf at infovore.xs4all.nl Thu Jan 9 20:10:22 2003 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.2 -- almost there II In-Reply-To: References: <877ke4jwlc.fsf_-_@infovore.xs4all.nl> <87u1h4fyum.fsf@infovore.xs4all.nl> <87ptr6xkru.fsf@infovore.xs4all.nl> Message-ID: <87hecixhpd.fsf@infovore.xs4all.nl> Peter Breitenlohner writes: > On Thu, 9 Jan 2003, Olaf Weber wrote: >> Right now, I give NO guarantees that something compiled against (say) >> kpathsea 3.4.1 will work with kpathsea 3.4.2. In practice, I believe >> that kpathsea 3.4.x is compatible with 3.4.y, and it is not impossible >> that 3.3.x is compatible with 3.3.y. > I see. I did notice a binary incompatibility between 3.3.8 (from > xdvik-22.40s.tar.gz) and 3.4.2 from web2c-7.4.2. Oh yes, the 3.3.x to 3.4 switch of numbers (and 7.3.x to 7.4.x) was made because I was certain the changes there destroyed binary compatibility: the bump was driven by kpathsea, in this case. > Certainly, but rather easy to achieve. I use a simple patch to do that for > linux-gnu, and I could look up libtool how this is done for other systems > and copy that to klibtool. > BTW: Some time ago you wrote that you intend to switch to libtool. Couldn't > (shouldn't) one also switch to automake? And switch to a newer autoconf > version, 2.13 is really ancient and I am surprised you still have that one > around. What is the current status? If you wish I could try to help. Let's see: We still use a hacked autoconf 2.13, because one bit of functionality (ac_include) was never adopted as such in newer autoconf. It can be "faked", but... There are some other items that make updating autoconf not completely straightforward. So I'm using the opportunity to get to actually understand the configure scripts and work them over in the new style. (One thing that came out of this is that I've new code for xputenv that I believe can do without the SMART_PUTENV tests.) The kpathsea rework uses libtool. It would be possible to use automake for kpathsea. Using it for web2c on the other hand is still comparatively painful: automake is not at its best when you have generated sources (C) created from generated sources (Pascal) possibly created from generated sources (WEB+TIE). -- Olaf Weber (This space left blank for technical reasons.) From karl at freefriends.org Thu Jan 9 21:08:11 2003 From: karl at freefriends.org (Karl Berry) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.2 -- almost there II Message-ID: <200301092008.h09K8BF08576@f7.net> We still use a hacked autoconf 2.13, because one bit of functionality (ac_include) was never adopted as such in newer autoconf. ac_include is still hanging around? I'd suggest either just using the builtin make `include', since it's unlikely anyone is using a make that doesn't support these days, or doing the include at dist time instead of configure time. Upgrading to a new autoconf, and not having to hack it, would be a good thing. (It also probably wouldn't be all that impossible to add ac_include to the latest autoconf, and maybe they'd even accept a patch ...) From olaf at infovore.xs4all.nl Thu Jan 9 22:22:39 2003 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.2 -- almost there II In-Reply-To: <200301092008.h09K8BF08576@f7.net> References: <200301092008.h09K8BF08576@f7.net> Message-ID: <87bs2q10io.fsf@infovore.xs4all.nl> Karl Berry writes: > We still use a hacked autoconf 2.13, because one bit of functionality > (ac_include) was never adopted as such in newer autoconf. > ac_include is still hanging around? Sure: it works, so why "fix" it? > I'd suggest either just using > the builtin make `include', since it's unlikely anyone is using a make > that doesn't support these days, or doing the include at dist time > instead of configure time. There are a number of changes coming together, with implications for the prereqs: ANSI C (not just for pdftex), a not-utterly-broken 'make' (especially if you want to build outside the source dir). But the variable substitution needed in the fragments means that they have to be processed by configure before being included: this in contrast to ac_include which does both at the same time. > Upgrading to a new autoconf, and not having > to hack it, would be a good thing. Absolutely. As long as we have to hack it, I might as well hack 2.13. > (It also probably wouldn't be all > that impossible to add ac_include to the latest autoconf, and maybe > they'd even accept a patch ...) Since I didn't want to hack autoconf, there's a "hook" that I tried to use; this turned out to be fairly hard, and never worked completely, due some some peculiarities of the substitution mechanism. -- Olaf Weber (This space left blank for technical reasons.) From peb at mppmu.mpg.de Fri Jan 10 09:53:43 2003 From: peb at mppmu.mpg.de (Peter Breitenlohner) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Re: messages from dek re tex 2002 In-Reply-To: References: Message-ID: On Thu, 9 Jan 2003, Olaf Weber wrote: > > 3) I also find the 8-bit character E-acute instead of ^^c8, > > and y-umlaut instead of ^^ff, in trip.log/mftrap.log when I say > > "make trip" and "make trap". This is probably OK, although it > > means that a very small part of tex and mf is not being > > exercised; but then such differences should probably appear > > in the files trip.diffs and mftrap.diffs. > > Actually, web2c adopts your system's notion of what characters are > printable from the active locale. This considerably enhances the > legibility of log files when people are working in languages where > accented characters are common. The results expected by trip and trap > appear when using the "C" locale. I think, the correct approach here is to enforce the "C" locale while running the trip/trap (or any of the other) tests. Peter Breitenlohner From peb at mppmu.mpg.de Fri Jan 10 10:00:47 2003 From: peb at mppmu.mpg.de (Peter Breitenlohner) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.2 -- almost there II In-Reply-To: <200301092008.h09K8BF08576@f7.net> References: <200301092008.h09K8BF08576@f7.net> Message-ID: On Thu, 9 Jan 2003, Karl Berry wrote: > We still use a hacked autoconf 2.13, because one bit of functionality > (ac_include) was never adopted as such in newer autoconf. > > ac_include is still hanging around? I'd suggest either just using > the builtin make `include', since it's unlikely anyone is using a make > that doesn't support these days, or doing the include at dist time > instead of configure time. Upgrading to a new autoconf, and not having > to hack it, would be a good thing. (It also probably wouldn't be all > that impossible to add ac_include to the latest autoconf, and maybe > they'd even accept a patch ...) Or just use automake, which resolves `include' when building Makefile.in, possibly without any automake generated build rules for the web2c stuff. I think automake's install rules are definitely an improvement, in particular Re: DESTDIR. But all that is definitely for a future version. Peter Breitenlohner From olaf at infovore.xs4all.nl Sat Jan 11 15:00:25 2003 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.3 -- almost there III Message-ID: <87y95rrdl2.fsf@infovore.xs4all.nl> I've put web2c 7.4.3 sources up on tug.org in ~ftp/tex. Thus they'll appear on CTAN in due course(?) The sources contain pdftex 1.10a RC3, Omega 1.23.2, and e-TeX 2.1. The difference with 7.4.2 are mainly for ctangle and cweave, which now support --help and --version options. What is NOT in this release: as you may have heard, Knuth has sent out an update to TeX and MF (and some smaller fry) for beta test. This isn't incorporated in this release -- it looks like the update is not trivial for both omega and e-TeX; we prefer to hold off Knuths new files until after teTeX 2.0 releases, so we can integrate them at our leisure. So we should be good for release at this point, except that we're still waiting for Godot^H^H^H^H^Hthe release of pdfTeX 1.10a. If, for some reason, you want the sources NOW and cannot log into tug.org, use the following links. http://www.xs4all.nl/~infovore/web-7.4.3.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.3-etex-2.1.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.3-omega-1.23.2.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.3-pdftex-3.14159-1.10a-RC3.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.3-pdftexlibs.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.3.tar.gz Otherwise use these: ftp://ftp.tug.org/tex/web-7.4.3.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.3-etex-2.1.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.3-omega-1.23.2.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.3-pdftex-3.14159-1.10a-RC3.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.3-pdftexlibs.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.3.tar.gz -- Olaf Weber (This space left blank for technical reasons.) From olaf at infovore.xs4all.nl Thu Jan 16 18:11:19 2003 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:25 2005 Subject: [tex-pretest] Web2C 7.4.4 -- arrival? Message-ID: <87u1g9f2a0.fsf@infovore.xs4all.nl> I've put web2c 7.4.4 sources up on tug.org in ~ftp/tex. Thus they'll appear on CTAN in due course(?) The sources contain pdftex 1.10a, Omega 1.23.2, and e-TeX 2.1. The difference with 7.4.3 are minimal. What is NOT in this release: as you may have heard, Knuth has sent out an update to TeX and MF (and some smaller fry) for beta test. This isn't incorporated in this release -- it looks like the update is not trivial for both omega and e-TeX; we prefer to hold off Knuths new files until after teTeX 2.0 releases, so we can integrate them at our leisure. We should be good (enough) for release at this point. If, for some reason, you want the sources NOW and cannot log into tug.org, use the following links. http://www.xs4all.nl/~infovore/web-7.4.4.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.4-etex-2.1.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.4-omega-1.23.2.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.4-pdftex-3.14159-1.10a.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.4-pdftexlibs.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.4.tar.gz Otherwise use these: ftp://ftp.tug.org/tex/web-7.4.4.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.4-etex-2.1.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.4-omega-1.23.2.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.4-pdftex-3.14159-1.10a.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.4-pdftexlibs.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.4.tar.gz There are quite a few nits that can be picked at this point, but I don't know of any showstoppers (yet?). -- Olaf Weber (This space left blank for technical reasons.) From olaf at infovore.xs4all.nl Fri Jan 17 21:51:42 2003 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:26 2005 Subject: [tex-pretest] Web2C 7.4.4 -- release notes (draft) In-Reply-To: <87u1g9f2a0.fsf@infovore.xs4all.nl> References: <87u1g9f2a0.fsf@infovore.xs4all.nl> Message-ID: <87vg0nsdnl.fsf@infovore.xs4all.nl> For the record, a not-so-brief note on how the sources relate to each other. This is probably going to be part of the official release notes, so comments are welcome. ---------------------------------------------------------------------- Important notes ---------------------------------------------------------------------- * Changed defaults. Note that some default settings of "tex, the Web2C implementation of TeX" have changed. We determined that some extensions were in fact in conflict with the strict definition of TeX as laid down by Knuth. The most notable change is that parsing of '%&' constructs in the first line of an input file is now disabled by default -- it can be enabled in texmf.cnf if you desire this. In that case, tex will announce itself as TeXk and print an additional banner line saying that %&-line parsing is enabled. We may encounter more places where the default behaviour is not what it should be, and proceed to make this optional (and by default off) in future versions of Web2C. * New programs. We've added ctangle and cweave to the programs bundled in the Web2C distribution. The sources are the Levy and Knuth sources, with additional change files to make them fit in with the other Web2C programs. ---------------------------------------------------------------------- Getting and compiling the sources ---------------------------------------------------------------------- * TeX, METAFONT, MetaPost, supporting programs. To compile the basic programs, you need the WEB sources and the Web2C tarball: ftp://ftp.tug.org/tex/web.tar.gz ftp://ftp.tug.org/tex/web2c.tar.gz Both of these must be unpacked in the same directory, as they complement each other. |Note that due to a problem in the top-level configure script, running |make in the top-level directory will fail due to unmet dependencies |on pdftex. Go one level deeper. To get a working system you also need a texmf tree. A barebones version sufficient for compilating can be found here ftp://ftp.tug.org/tex/texmf.tar.gz You're strongly encouraged to obtain a pre-prepared tree that is more full-featured, for example the texmf tree used by the teTeX distribution. The texmf tree must be unpacked in a location where you'd store shared program data files, like /usr/local/share. Note that installation will want to write files in the "web2c" directory of the texmf tree. Out of the box, the sources will work well with a texmf tree but not with the older style of storing the data files which didn't bundle directories like that. In such a case edit texk/kpathsea/texmf.in to be correct for your site before building. * Adding e-TeX To add e-TeX, you need to add the following to the sources ftp://ftp.tug.org/tex/web2c-etex.tar.gz It adds the e-TeX sources to the web2c source tree. Unpack it in the same directory in which you unpacked web.tar.gz and web2c.tar.gz. This must be done before you run configure. Also add the following to the texmf tree: ftp://ftp.tug.org/tex/etexlib.tar.gz This tarball adds e-TeX documentation the texmf tree: ftp://ftp.tug.org/tex/etexdoc.tar.gz * Adding Omega To add Omega, you need to add the following to the sources ftp://ftp.tug.org/tex/web2c-omega.tar.gz It adds the Omega sources to the web2c source tree. Unpack it in the same directory in which you unpacked web.tar.gz and web2c.tar.gz. This must be done before you run configure. Also add the following to the texmf tree: ftp://ftp.tug.org/tex/omegalib.tar.gz |Beware: this set of files is outdated. This tarball adds Omega documentation the texmf tree: ftp://ftp.tug.org/tex/omegadoc.tar.gz |Beware: this set of files is outdated. * Adding pdfTeX To add pdfTeX, you need to add the following to the sources ftp://ftp.tug.org/tex/web2c-pdftex.tar.gz ftp://ftp.tug.org/tex/web2c-pdftexlibs.tar.gz The first tarball adds the pdfTeX sources, the second adds the sources for libraries that pdfTeX requires, including a version of xpdf set up to compile into a library. Unpack them in the same directory in which you unpacked web.tar.gz and web2c.tar.gz. This must be done before you run configure. Also add the following to the texmf tree: ftp://ftp.tug.org/tex/pdftexlib.tar.gz |Beware: this set of files is outdated. ---------------------------------------------------------------------- Why the sources are organized this way. ---------------------------------------------------------------------- * Why so many tarballs? This is partly for historical reasons, partly due to the way the various pieces came together. Web2C, e-TeX, Omega, and pdfTeX all have different groups of maintainers, and change at different speeds. This setup made it easier to replace one version of Omega with another when doing development. In a similar vein, the texmf tree parts for the different programs have different maintainers and should be updated by different groups. That, at least, is the theory. This has by now largely broken down, as shoulde be evident from the fact that some of the library tarballs are badly outdated. * Why not a single tarball? Combining the sources above into a single tarball was done for a while. To this were also added kpathsea-enabled versions of dvilj, dvips and xdvi. These add three more packages that have yet more maintainers. A reason to want to put them all together into a single tarball is that libkpathsea is needed by all of them, and doesn't work all that gracefully as a separately-installed library. The pattern was that the texk distribution acquired even more programs over time. In this it began to approach a considerable subset of the teTeX distribution. This was a considerable waste of effort, so I briefly tried to make it a genuine subset of teTeX. But in that case, what's the point anyway? So I decided to stop with texk as a separate distribution, and instead concentrate on just the core Web2C parts, plus helping with the integration of e-TeX, Omega, and pdfTeX into Web2C. * The current situation. Currently web2c with its extensions and kpathsea are embedded in teTeX. The teTeX distribution is itself embedded in TeX-live; in fact TeX-live and teTeX are maintained using the same source repository. I do Web2C development on my own machine, with my own CVS repository, and make updates available to Thomas Esser (teTeX), Sebastian Rahtz (TeX-live), Fabrice Popineau (fpTeX), and whoever else happens to be interested and willing to endure the hassle (the Omega developers spring to mind). * Future directions: short term. The Omega sources are currently nested inside the Web2C source tree. In future versions they will be a separate source tree, though one that still uses the build infrastructure provided by the Web2C sources. This tree would typically be a sibling of the web2c tree. * Future directions: long term. As I've noted above, kpathsea is not exactly graceful as a library. I'm working on changing it to a well-behaved (shared) library. This does have consequences for the programming interface (API) as well as the binary interface (ABI). The configuration scripts and other parts of the build infrastructure are old -- they work well enough that we've never been forced to upgrade, but we're getting to the point where it makes sense to do so nevertheless. The "new" kpathsea (when it is ready) will prompt that upgrade. -- Olaf Weber (This space left blank for technical reasons.) From olaf at infovore.xs4all.nl Wed Jan 29 23:04:52 2003 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:26 2005 Subject: [tex-pretest] Web2C 7.4.5 Message-ID: <87znpjtxx7.fsf@infovore.xs4all.nl> I've put web2c 7.4.5 sources up on tug.org in ~ftp/tex. Thus they'll appear on CTAN in due course(?) The sources contain pdftex 1.10a, Omega 1.23.2, and e-TeX 2.1. The difference with 7.4.4 are minimal. What is NOT in this release: as you may have heard, Knuth has sent out an update to TeX and MF (and some smaller fry) for beta test. This isn't incorporated in this release -- it looks like the update is not trivial for both omega and e-TeX; we prefer to hold off Knuths new files until after teTeX 2.0 releases, so we can integrate them at our leisure. We should be good (enough) for release at this point. If, for some reason, you want the sources NOW and cannot log into tug.org, use the following links. http://www.xs4all.nl/~infovore/web-7.4.5.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.5-etex-2.1.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.5-omega-1.23.2.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.5-pdftex-3.14159-1.10a.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.5-pdftexlibs.tar.gz http://www.xs4all.nl/~infovore/web2c-7.4.5.tar.gz Otherwise use these: ftp://ftp.tug.org/tex/web-7.4.5.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.5-etex-2.1.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.5-omega-1.23.2.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.5-pdftex-3.14159-1.10a.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.5-pdftexlibs.tar.gz ftp://ftp.tug.org/tex/web2c-7.4.5.tar.gz There are quite a few nits that can be picked at this point, but I don't know of any showstoppers (yet?). ---------------------------------------------------------------------- Release notes for Web2C 7.4.5 / kpathsea 3.4.5. ---------------------------------------------------------------------- Important notes ---------------------------------------------------------------------- * Changed defaults. Note that some default settings of "tex, the Web2C implementation of TeX" have changed. We determined that some extensions were in fact in conflict with the strict definition of TeX as laid down by Knuth. The most notable change is that parsing of '%&' constructs in the first line of an input file is now disabled by default -- it can be enabled in texmf.cnf if you desire this. In that case, tex will announce itself as TeXk and print an additional banner line saying that %&-line parsing is enabled. We may encounter more places where the default behaviour is not what it should be, and proceed to make this optional (and by default off) in future versions of Web2C. * New programs. We've added ctangle and cweave to the programs bundled in the Web2C distribution. The sources are the Levy and Knuth sources, with additional change files to make them fit in with the other Web2C programs. * Building libkpathsea as a shared library. On some platforms libkpathsea can be built as a shared library, though I cannot at present recommend that you do so. But if you did so in the past, note that a program linked against a 3.3.x version of libkpathsea cannot use the 3.4.x version. If you need to keep both 3.3.x and 3.4.x versions around, you're on your own as to how to get this to work. ---------------------------------------------------------------------- Getting and compiling the sources ---------------------------------------------------------------------- * TeX, METAFONT, MetaPost, supporting programs. To compile the basic programs, you need the WEB sources and the Web2C tarball: ftp://ftp.tug.org/tex/web.tar.gz ftp://ftp.tug.org/tex/web2c.tar.gz Both of these must be unpacked in the same directory, as they complement each other. * Note that due to a problem in the top-level configure script, running * make in the top-level directory will fail due to unmet dependencies * on pdftex. Go one level deeper. To get a working system you also need a texmf tree. A barebones version sufficient for compilating can be found here ftp://ftp.tug.org/tex/texmf.tar.gz You're strongly encouraged to obtain a pre-prepared tree that is more full-featured, for example the texmf tree used by the teTeX distribution. The texmf tree must be unpacked in a location where you'd store shared program data files, like /usr/local/share. Note that installation will want to write files in the "web2c" directory of the texmf tree. Out of the box, the sources will work well with a texmf tree but not with the older style of storing the data files which didn't bundle directories like that. In such a case edit texk/kpathsea/texmf.in to be correct for your site before building. * Adding e-TeX To add e-TeX, you need to add the following to the sources ftp://ftp.tug.org/tex/web2c-etex.tar.gz It adds the e-TeX sources to the web2c source tree. Unpack it in the same directory in which you unpacked web.tar.gz and web2c.tar.gz. This must be done before you run configure. Also add the following to the texmf tree: ftp://ftp.tug.org/tex/etexlib.tar.gz This tarball adds e-TeX documentation the texmf tree: ftp://ftp.tug.org/tex/etexdoc.tar.gz * Adding Omega To add Omega, you need to add the following to the sources ftp://ftp.tug.org/tex/web2c-omega.tar.gz It adds the Omega sources to the web2c source tree. Unpack it in the same directory in which you unpacked web.tar.gz and web2c.tar.gz. This must be done before you run configure. Also add the following to the texmf tree: ftp://ftp.tug.org/tex/omegalib.tar.gz * Beware: this set of files is outdated. This tarball adds Omega documentation the texmf tree: ftp://ftp.tug.org/tex/omegadoc.tar.gz * Beware: this set of files is outdated. * Adding pdfTeX To add pdfTeX, you need to add the following to the sources ftp://ftp.tug.org/tex/web2c-pdftex.tar.gz ftp://ftp.tug.org/tex/web2c-pdftexlibs.tar.gz The first tarball adds the pdfTeX sources, the second adds the sources for libraries that pdfTeX requires, including a version of xpdf set up to compile into a library. Unpack them in the same directory in which you unpacked web.tar.gz and web2c.tar.gz. This must be done before you run configure. Also add the following to the texmf tree: ftp://ftp.tug.org/tex/pdftexlib.tar.gz * Beware: this set of files is outdated. ---------------------------------------------------------------------- Why the sources are organized this way. ---------------------------------------------------------------------- * Why so many tarballs? This is partly for historical reasons, partly due to the way the various pieces came together. Web2C, e-TeX, Omega, and pdfTeX all have different groups of maintainers, and change at different speeds. This setup made it easier to replace one version of a program with another when doing development. In a similar vein, the texmf tree parts for the different programs have different maintainers and should be updated by different groups. That, at least, is the theory. This has by now largely broken down, as should be evident from the fact that some of the library tarballs are badly outdated. * Why not a single tarball? Combining the sources above into a single tarball was done for a while. To this were also added kpathsea-enabled versions of dvilj, dvips and xdvi. These add three more packages that have yet more maintainers. A reason to want to put them all together into a single tarball is that libkpathsea is needed by all of them, and doesn't work all that gracefully as a separately-installed library. The pattern was that the texk distribution acquired even more programs over time. In this it began to approach a considerable subset of the teTeX distribution. This was a considerable waste of effort, so I briefly tried to make it a genuine subset of teTeX. But in that case, what's the point anyway? So I decided to stop with texk as a separate distribution, and instead concentrate on just the core Web2C parts, plus helping with the integration of e-TeX, Omega, and pdfTeX into Web2C. * The current situation. Currently web2c with its extensions and kpathsea are embedded in teTeX. The teTeX distribution is itself embedded in TeX Live. I do Web2C development on my own machine, with my own CVS repository, and make updates available to Thomas Esser (teTeX), Sebastian Rahtz (TeX Live), Fabrice Popineau (fpTeX), and whoever else happens to be interested and willing to endure the hassle (the Omega developers spring to mind). Usually, Thomas updates teTeX with my release, and then pushes the new teTeX into TeX Live. If changes had to be made by him one of the others, they are often copied into Web2C from TeX Live, completing the circle. * There's a huge jump in version numbers, what happened? For me, the main reason to use version numbers is that when I get a bug report, I can tell which version of the sources it belongs to. For a while I used version numbers of the form X.Y.ZbetaN to indicate releases that for one reason or another I did not consider ready for prime time. But this is too much of a bother if you're only doing it to keep version numbers from changing too fast. So I've switched back to the X.Y.Z numbering scheme. The "missing" numbers belong largely to versions that went out with teTeX beta releases. And a number of X.Y.Z versions were released as part of TeX Live released, but sometimes with a little appended x to indicate that the TeX Live sources were based on but not identical to that version. * Future directions: short term. Don Knuth has made some (small) updates to several WEB source files. We're already working on integrating them, but knew that work couldn't be finished in time for this release. The Omega sources are currently nested inside the Web2C source tree. In future versions they will be a separate source tree, though one that still uses the build infrastructure provided by the Web2C sources. This tree would typically be a sibling of the web2c tree. * Future directions: long term. As I've noted above, kpathsea is not exactly graceful as a library. I'm working on changing it to a well-behaved (shared) library. This does have consequences for the programming interface (API) as well as the binary interface (ABI). The configuration scripts and other parts of the build infrastructure are old -- they work well enough that we've never been forced to upgrade, but we're getting to the point where it makes sense to do so nevertheless. The "new" kpathsea (when it is ready) will prompt that upgrade. -- Olaf Weber (This space left blank for technical reasons.)