Re: Tux Racer 0.10 Released

[Steve Baker <sjbaker1@airmail.net>]

Erik Thiele wrote:

> it would be better if compilation would work better.

> 2) something like plib is not really a lib if it always changes
>    together with the main package, and if it only works if you
>    always have the bleeding edge version because
>    it's interface (header files) are always changing.

That's not really fair.  Tux_AQFH is in rev 1.0.10, so there
have been 10 public versions released.  PLIB is 1.1.11 and
has been through about 29 public versions. Clearly the
two packages are not progressing in lock-step.

PLIB *is* a library because it's used by LOTS of packages
so it's not tied just to Tux_AQFH.

> I'm afraid it's like that ;)
> I hate that fiddling around with that autoconf stuff
> takes many time in my software development.
> but i wrote several macros that i always reuse and have
> minimized effort.
> 
> It's just you have to do it ;)
> Then you'll see how stupid autoconf can be and how disgusting.
> then you'll think there should be a complete rewrite of that crap.
> but in the end you must notice that currently there is no better.
> so use it :-) you have no choice.
> 
> for tux_aqfh and plib my very-concrete suggestions are:
> 
> a) integrate plib and link statically.

PLIB only links statically - there is no '.so' version. However,
releasing PLIB with Tux would be unfair to all the other packages
that use it.  Would users REALLY want to repeatedly download
PLIB for each other thing that uses it?

Besides, PLIB isn't the problem - 99% of the problems (that I
find out about) are associated with Mesa.

Quake gets around that by distributing Mesa along with it - but
that's impossible for a lone developer because I can't distribute
versions for a half dozen different 3D adaptors.  With the advent
of Mesa-embedded-in-Xfree4.0-with-DRI, even Quake won't be able to
do that.

> b) keep plib as a seperate package. but then:
>    a) make sure that the interface stabilazes so that in 6 months or so
>       maybe 40% of the INSTALLED distributions have that version. :-)
>       and then you can start really using it.
>       without (!) the need to update it with every tux_aqfh version

This should happen with PLIB 1.2 since I'm going to an odd/even distribution
mechanism where there will be a stable (even numbered) version that changes
VERY rarely and a development (odd numbered) version that's getting all
the cutting edge work done on it.  I'm pretty close to getting it stable
enough to do that....but then there is never a truly GOOD time to do that.

>    b) if that's not possible, you must make it possible to quick
>       upgrade a new plib. therefor
>         - make it possible to install plib without root. see above.
>         - add options in aqfh configure to specify plib paths.
>         - accept that people hate your plib because of version chaos.
>           ("i have that 4 programs using 3 different versions
>           of plib on my system")
>           this may lead to removal of plib from distributions because
>           of unresolvable problems.
>           for example. what is the use of plib version 1.1.5 in the
>           not yet stable current debian release?

Well, that's harder to answer - and I accept this criticism.  There
was a time (just around when I went to 1.1.xx) when you needed 3
versions - but only if you were working on PPE - for most people
there were only 2 versions that you ever needed.  Even the C standard
library has *that* problem (libc 5, glibc 6 and glibc 6.1).

Right now, all PLIB applications that I'm aware of work just fine
with any of the last half dozen PLIB versions.  Things have gotten
MUCH better over the past three or four months.

> or something like that
> 
> personally i vote for full integration of plib to reduce
> compilation complexity!

But it's not PLIB that causes 99% of the compilation problems,
it's Mesa.  

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)



---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk