[tex-k] Twiki is broken; sorry . . . let's use tex-k list if that's okay.

[Thomas Esser]

Hi Karl,

great to see you jump into this discussion!

>     I  think that there is  a better  solution which  is  based on a small
>     kpathsea package where these drivers could be based on. 
>
> This would be ideal.  Unfortunately, when I was creating/maintaining

Ok, I think that we agree on this point.

> kpathsea and its predecessor code, I found that the problem with
> creating such a thing was the Makefiles and build process.  Kpathsea
> needs to make so many assumptions in order to build properly on all the
> systems out there, any drivers or whatever else that uses it ends
> up having to use the same build process, in practice.  Everything has to
> agree on the preprocessor symbols to use ...

As for this technical things, I tend to disagree (i.e. I think that I
am right, but I cannot prove it right now). Autoconf checks need not
to be replicated if drivers include kpathsea/c-auto.h before any other
kpathsea header file (which currently all drivers in "texk" do).

> From the users' point of view, they just want to download something that
> works.  Most people get texlive or tetex, but wanting to download a new
> dvips or xdvi between tetex/texlive is not unreasononable or uncommon.

Yes, absolutely.

> And expecting a dvips-only source tree to build against an
> already-installed kpathsea ... Well, it would be ideal, but I think it
> would be a lot of time, which in practice driver maintainers want to
> spend on improving the driver, not messing with build junk.

It might help if someone (me?) could prepare a "reference" implementation
for a driver which ideally:
  - could compile against an already installed kpathsea
  - could also compile its own kpathesa and link against it either
    statically or dynamically
  - could use a cut-down "texk" source tree

> Hoping for a Grand Agreement where everyone uses the same source
> hierarchy (p4, sourceforge, savannah, cvs, whatever) seems unduly
> idealistic to me.  Variety is the spice of life.

Right, but there is one point which could make maintenance of teTeX / TeX
Live (and anything which is web2c/kpathsea + something) a little easier
and this is the way how driver plug into a web2c/kpathsea source tree.
In my poinion it would help if this interface on the source code level
was as small (and as stable) as possible. I think that xdvik, dvipsk,
ps2pkm, dviljk, ... can easily be decoupled from some kpathsea
"internals". It is nice to
  ac_include ../make/paths.mk
  ac_include ../make/common.mk
  ac_include ../make/programs.mk
in Makefile.in and get lots of things automatically right, but I don't
think that this is really necessary.

Thomas