Which can be done just fine and just as easilly (moreso, actually) if things are in the same lib.

The size difference will be negligible.

And if you needed the extra space that badly, you can compile a custom version.

Debateable. You can modularize the library without having to split it up.

It would still offer the same exact functionality...

You haven't shown how, nor have you countered my and tobing's arguments that it will. All you've basically said is "No, it won't."

You replied by saying that we'd just have to keep better track of these things.. which is exactly the argument that it'd just make more work for the developers.

I disagree that it'll be easy.Instead of maintaining 1 package, you'd be maintaining and coordinating multiple package. It implicitly increases work load.

Perhaps something more along the lines of the following could be done:

Make the allegro core (as I described earlier) either static linkable or dynamically linkable. Your allegro dll would come from this.

Default the extensions (plugins) to being statically linkable. The user can create a dynamically linkable dll if they so wish, but the resultant dll is 100% custom to the user, not allegro specific (aka, the dll can contain any number of functions that the user desires).

This way, the developer has a couple options: there is only one, core, allegro DLL. The timer routines, bitmap routines, and all of the standard goodies go into this. Anything else that is considered a "plugin" (and thus automatically available by some magic allegro\plugins\fill_in_the_blank.h header) is therefore optionally linkable.

There could even be a compatability dll that has these "potentially unnecessary" functions compiled into it. (True, users would not be required to generate or use such a dll unless the developers use it, and a depriciation warning could be thrown on that).

This helps prevent versioning-hell (from our end, anyway), and allows the user to create versioning hell if he so desires (make his own dlls though some magical makefile system). It also has the added advantage that the plugin would be required to play nice with the library core. No more dirty hacks, no more unpredictable side effects from a plugin altering something it shouldn't.

This could be a potential comprimise. The problem is that currently a) there needs to be a way to NOT (keyword, NOT) compile certain features into an allegro application if you have absolutely no need for them. b) the current library code has too many cross-refrences to other pieces of code to be easily "hacked" to the point that this can be achieved.

I think this would be a reasonable comprimise:

1) Use the allegro dll that contains only the core code (anything else is staticly linked or done with a custom dll)

2) Create a custom allegro dll that contains anything and everything you want (this dll would have to be managed and maintained by the developer in question, however).

3) Create a compatability dll that contains the current interfaces for backwards compatability reasons.

As long as everything isn't rigidly statically linked, it's fine.. Ideally it's up to the user if he/she chooses to have the font routines in a DLL or statically linked ..

KC: Yeah, that was kindof the generic Idea. The idea behind the whole theory I posted in the last post is that A) most devs end up shipping an allegro dll anyway, so it might as well be static linked, and B) it provides an interesting method for "compilable" custom dlls.

Of course, it would be possible to have an "uber" dll that has everything officially supported by allegro in one single DLL, assuming that all of the proper "offical" allegro pacakges are in the addons directory.

You could even have one unofficial "uber" dll if you want (assuming you have someone else who dictates what exactly is and isn't part of that uber dll).

I think I like the way this discussion is heading. Any other comments?