[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tux Racer 0.10 Released

On Mon, Mar 20, 2000 at 02:10:36PM +0100, Thomas Lund wrote:
> I myself did not send any reports to you about buggy/hard installation,
> since there are TONS of projects out there. If I had to report things
> that do not work on each and every one of them, I would not have time to
> do anything else.
yes ;) there is so much software.
everybody releases everything
and i have implemented some sort of quick filter in my brain.
software falling through that filter doesn't even get a bugreport ;)

although you might think this is bad, and probably you are right,
i still think this is the way it works for most people.

> The typical way I check out a new game/application/whatever is:
> * if I can install easy (using RPM) I will try it, run it and remove if
> I don't like it
there is also .deb ;) don'T forget.
but i never installed a .deb or .rpm from some third party website.
this is zero security. it's just like binary .tgz packages.
either the program is compilable and runnable without being root,
or i drop it. and i never ran a pre-compiled binary from a website.
but i am not everybody :)

> * if I have to compile I give it a one shot. I will rather use a
> packaged binary to not clutter up my system with obscure libs that I
> have a hard way to remove again
well. thats what
   ./configure --prefix=/home/erik/localinst/mygame
   make install
is for.
you can then rm -rf ~/localinst/mygame
and the thing is gone completely.
all you need to do for this is

a) the configure option
b) export PATH="$PATH":~/localinst/mygame/bin
c) (if needed) export LD_LIBRARY_PATH=\
d) add those stuff to your login script.
e) if the thing you installed was a library, you must add
   configure options to all the packages you compile with
   this library.
   tuxracer> ./configure --with-plib-include=~/localinst/plib/include

for example i installed
circuslinux,madbomber and that gauntlet clone like this.
they wanted an additional library, the libSDL_mixer.
and i can remove all that crap again. quick,completely
and all without being root.

> Would it not be possible to create a binary with static linked plib,
> SDL, whatever lib is needed? Possibly except Mesa, since that is usually
> system dependant.
maybe some people like that,...
mostly the windows users that are used to installing something
where they do not know what it is ;)))

it would be better if compilation would work better.

1) programs may not use bleeding edge libraries. for example
   the old SDL versions are working, too.
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.

no matter what you do. but if you don't change anything,
very few people will be interested in 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.
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
   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?

or something like that

personally i vote for full integration of plib to reduce
compilation complexity!


PS: i know i said several things twice, but i have bonus because
    english is not my native language ;)

Name:  Erik Thiele                                       \\\\
Email: erikyyy@erikyyy.de                                o `QQ'_
IRC:   erikyyy                                            /   __8
WWW:   http://www.erikyyy.de/                             '  `

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