[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why code your own library?
> 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
> 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
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.
* ./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
* 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
firstname.lastname@example.org (home) http://www.woodsoup.org/~sbaker