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

Re: Why code your own library?

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
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

> 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
even need to be aware of all the other libraries you did or didn't

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
script - and the authors of those libraries would have to include
scripts that in turn pull in whatever libraries they in turn need.

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

It seems to me that this is a natural 'web-based' extension of

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)