Re: [AD] Possible new features for Allegro?

[Bob <ohannessian@xxxxxxxxxx>]

Hein Zelle wrote:

> re: (whole thread)
>
> Good grief indeed, George.
>
> I still don't understand why everybody dislikes separate packages so
> much. (Well, I can guess, but I'll come to that in a minute). I truly
> prefer allegro being simple and non-bloated. Most games use only half
> of what allegro can do, and even though it's a library I think we
> should realize that in many cases it will be preferable to only include
> what you use and no more.
[snip]


I've been tossing the idea around for a while now, and here's what I'd 
propose (fell free to poke holes at it - I can't possibly think of everything :)

Allegro can have super make files. The makefiles would detect add-ons (more 
on that later), and compile them all by themselves.

Add-ons can contain micro-makefiles which would indicate how to build the 
add-on, and if any special process is needed (assembler? sed? etc).

Allegro (5) should be only a core (to define the API), caps falgs, and hooks 
to add just about every functionality.

Users can then download add-on packages from the Allegro site. For example, 
if you want graphics, get the Allegro-graphics-core package, and possibly a 
few extra drivers you'd like to support (DOS/Vesa, OpenGL, Windows/DDraw3 or 
DGraphics, etc). If you also want sound and 3d software rendering, you can 
download those packages too.

To install the packages, simply unzip them in the Allegro directory (the 
packages themselves contain path information to make them unzip in the 
appropreiate sub-dirs). The add-ons will drop some information files (kinda 
like the grabber plug-in system), indicating their name, the hooks they use, 
what they do, and if there are any dependencies.
Run 'make', and all the packages get compiled in their own DLLs.

Since we have this add-on system, we can release Allegro-lite (just the core 
with maybe the memory graphics system), Allegro-Normal (the current Allegro 
4 features), or Allegro-Zilla (everything). This can all be done via the 
zipup.sh script for instance.

This leaves the problem of having 200 DLLs to distribute/lying around. If 
DLLs can be packaged into archives of some sort, then this could alleviate 
part of the problem. We could also design a system like QuickTime: when an 
Allegro program starts, the Core detects which packages it needs, and which 
DLLs are installed. If it needs additional DLLs, it can either present a 
dialog box with a list, or even an option to automatically download and 
install them for the user.


George suggested that (current) drivers get included with their respective 
cores to reduce the DLL problem.

For Unix systems, replace DLL with .so :)

Thoughts, comments?

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/