Re: Why code your own library?

[Steve Baker <sjbaker1@airmail.net>]

Erik wrote:
> 
> I haven't tried tux because in addition to the game itself, it required a meg
> of d/l to install some library system all over...

That would be PLIB.

> Last I checked on flight
> gear, it did not require the plib libraries externally.

It certainly has for at least the last 6 months.  And once you have
PLIB installed for (say) Tux, you don't need to reinstall it for
FlightGear
or Majik-3D.

> It may very well have
> plib imbedded into its source tree, but it's still a single source tree. When I
> tried it, I just downloaded the game itself and went from there.

Not any more.  FlightGear was incorporating PLIB into their release
because it was a very incomplete package back then and they needed
some custom hacks that hadn't made it into mainstream PLIB. However,
when Tux was released we all agreed to make it a separate download.

You wouldn't want to do that download twice - once for each game.

erm - Technically, FlightGear isn't a game - it's a "real" flight
simulator -
I don't think it's authors would like it to be called a "game".  YMMV
however.

> a year ago I woulda agreed. Now I see a lot of linux users who can't figure out
> how to type "rpm -i blah.rpm" and need gtar or something to unpack an archive.
> Maybe I'm just seeing the bad side of it, but it sure feels like linux is
> getting dumbed down for the average winiot to have a turn :(

Yep.  It's hard to know what to do about that.

> static linking can lead to licensing problems :) Quality is definitly
> important, but if your game requires that lib and this api and that and this
> and something else before they even get to see it, a lot are gonna quit before
> they get to see your hot high quality awesome game.

I wondered if it would be possible to build some kind of tool into the
download process itself.

Suppose, instead of doing:

* Download a huge tarball.
* gunzip
* untar
* ./configure ; make ; make

...you were to:

* Download a tiny script called "autoget" or something.
* Run "./autoget"
* Sit back and wait for everything to happen - whilst autoget:

  * Checks what libraries you have and which are missing (and which
    need upgrading).
  * Uses 'wget' (or some similar mechanism) to download the "autoget"
    script for each missing library and run it for you.
  * Finally, download the object you originally wanted.
  * gunzip/untar/configure/make/make install.

(Notice that this is recursive - my autoget loads other autogets that
may in turn pull in others)

Hence, when you built a program for distribution, your poor user
wouldn't
even need to be aware of all the other libraries you did or didn't
install.

Of course for this to work, the location of a web site containing the
libraries you depend on would have to be included in your game's
"autoget"
script - and the authors of those libraries would have to include
"autoget"
scripts that in turn pull in whatever libraries they in turn need.

Autoget could also be hand-edited to include commands to download,
unpack
and build packages that don't conform to this standard.

It seems to me that this is a natural 'web-based' extension of
autoconf/automake.

I proposed this to the authors of those two packages - but whilst they
expressed sympathy for the idea, they didn't seem too interested in
doing this themselves.  I don't have the time myself.

I wonder if you could write a netscape plugin that would run the autoget
script automatically when you clicked on it?  Then, getting a game
would be *JUST* a matter of clicking on a link to the autoget
script.  One mouse click game installation!

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