So would I, but I'm objecting to the "whatever doesn't break the library only makes it stronger" statement. Nothing else. I'd love to see PNG and OGG support in the core library as well, but that statement up there is just asinine. That's the kind of statement that leads to Allegro having Fourier transform functions, because it "doesn't break the library".

Most users would already have the Windows and DirectX DLLs. Most won't already have the extra Allegro DLLs.

Redistributable Allegro distribution? The current Allegro distro is redistributable already...

Having many seperate DLLs for one library doesn't make a game feel more commercial. If anything, just the opposite.

"game.exe + data.dat + allegxx.dll" vs "game.exe + data.dat + alleg-xx-core.dll + alleg-xx-imgldrs.dll + alleg-xx-sndldrs.dll + ..."
or for source distribution:
"You need Allegro version x or better" vs "You need Allegro core version x, Allegro image-loaders version y, Allegro sound-loaders version z, ..."

Splitting up the library will make more DLLs, which will cause more DLLs to be in the game's directory, which is clutter.

Not everyone is (I'd say most aren't) going to bother with an installer. Especially for source distributions.

Windows doesn't allow that. If the DLLs aren't somewhere in %PATH% or the current working directory, it won't be loaded.

Rule of thumb: If you have to ask a Windows user to do something more than double click here and there, they aren't going to do it. Yes I know they're not all like that, but it's a nice rule of thumb to go by. And you do not want to modify a user's system settings on them.

Which defeats the entire purpose of DLLs, which is shared code and ease of upgrading the lib without recompiling the exe.

Um, why are we even putting the DLL code in the program directory then, KC? If every program that uses allegro includes its own copy of the DLL, then we are defeating the purpose of "sharing" the code to begin with. The point is that the allegro dlls are and should be handled behind the scenes; aka, in the c:\windows\system32 directory. This way all allegro programs use the same DLL. This ensures that the DLL is in a commonly accessable location. It also prevents windows users from having to mess with pathing or having a cluttered directory; just copy the dlls to the system32 folder with the installer if they don't already exist, and viola! you're done. No more clutter, no more duplicated DLLs.

EDIT:
And even this definition of the reason allegro is in a DLL is rather flawed. True, you can try to use a new DLL with an older version of the executable, but so many things are changing (especially with WIP releases) they are bound to be broken.

The multiple DLL clutter issue is really a moot point. Most users never even look at the programs directory to begin with; they just extract and run a shortcut. Who cares what the dlls look like in the directory? If it makes updating easier for us, the developers, then I say go for it.

I mean, here, lets look at some more "common" programs and their DLLs in their directories:

Starcraft w/ Broodwar - 5 Dlls in the root directory
Battlefield 1942 - 4 DLLs in root
Total Annialation - 9 DLLs
Valve's Steam - 5 DLLs
Blender - 3 DLLs
GIMP - 17 DLLs in the Bin Directory (where gimp.exe is located)
OpenOffice.org - 200 DLLs in Program directory (where soffice.exe is located).

DLL clutter is VERY common, and really isn't a problem, unless you like to browse your program directory daily and on a regular basis. Here, try this for a rule of thumb: if the user has to be messing around in the program directory to get things working, there is something wrong besides the DLLs in the directory.

The problem is not code reuse, it is the fact that some portions of the library may become "more stable" at a more rapid rate than others. Thus, these portions of the library would be upgradable independantly of any other "lesser" sections. The problem right now is that while certain parts of the library are maturing at a decent rate, other parts are lagging behind, pushing back "stable" release dates for other features.

Splitting was never designed to increase code re-use; it is designed to prevent redundant updates and to expidite development of the library in various areas. (Not to mention it helps remove the libraries dependancy on all sections of itself. If a person wants to use allegro for nothing more than a hardware wrapper (no "frosting" functions), they only include one, much smaller DLL, instead of including one much larger dll in their installer.)

@KCat.. look at the point:

1. Linking statically doesn't share the common code. (agreed)
2. Linking dynamically doesn't make a difference when there is one DLL or two DLLs or 200 (agreed)
3. DLLs increase file clutter : you mean to say, I have 300 Allegro games and there will be 300x alleg4x.dlls or 300 x 3 = 900 DLLs? So where did all that code sharing go?
(flame here)
4. Splitting the library isn't going to cost the developer/producer/publisher (flame here)
5. The gamer (user) doesn't bother if there are some 3000 DLLs in that directory. He just double clicks the EXE file, plays the game and stays happy. (agreed)
6. Splitting the library does make it easy for Allegro-Developers. (agreed)
7. The developers are going to get the whole package, just more organized. They don't lose anything. They'll gain when Allegro gets more loaders into the extensions package... Their code won'tt not need any re-compilation.. Coz updating the alleg-stdext.dll will cause a load_bitmap() to load a PNG file in the future. it's just like updating to a newer version of alleg41.dll .. No difference, see?!!

seriously, give me good reasons as to what makes it too hard to follow? And a good reason is not like:

"it's been like this all this years, and I don't like it"

@Tobing:

Versioning hell is a problem, eh? Try running a 4.1.18 compiled game with a 4.1.16 dll, did it make any difference? These arguments are just lame. DLL hell with one DLL, DLL hell with 10 DLLs

P.S.: I, as an Allegro user am ready to change my makefile if it's going to help Allegro in the long run.

Eh, frankly, I don't care. As long as allegro either A) eventually supports automatic compilation and detection of plugins (evert's idea sounds really cool) or B) includes all of the features any decent modern gaming library solution should contain, I'm happy. The problem is that it gets, as stated previously, very annoying to get everything setup and working properly when all of the libraries have their own build systems, quirks, dependancies, bugs...

Now, if the makefile could somehow be tweaked to automatically detect the plugins and compile them, that would be one sweet setup. I could go for that.

Something like

1) You copy a standardized plugin directory into the allegro\plugin directory.
2) Run make in the root allegro directory.
3) Run make install to install all of the necessary libraries, DLLs, headers, etc.

This would have some unique implications as well. We could provide a standard method for plugins to add features to the grabber utility, for instance; or add new pages to the documentation; or add more libraries to the *nix command `allegro-config --libs`.

I could really go for a system like this. At the very least we would be providing a common framework for plugins to be built upon.

EDIT:

Although, I think we can all agree that the allegro core could be a bit more modularized. The unneeded functions could be moved into the plugin system that evert mentioned. That way, they could be "removed" without destroying the rest of the system. Of course, this complicates things because either we have to A) statically link these functions, B) create a dll for all of the plugins seperately (version hell), C) create a single Allegro DLL with all of the plugins (version hell), D) create an individual DLL for each plugin (slightly less version hell)

No need to flame here. I'm working in a project involving a bunch of DLLs, so I DO know what the versioning problem is. That's the reason why we decided to only deliver complete packages to our customers: You have to verify correctness of every combination of DLLs you're going to release. The sheer number of possibilities to get strange errors with multiple DLLs of different versions is endless, and nobody would like to try to debug those bugs.

It depends on what the problem was. Maybe to fix the problem there had to be an addition to the core.

What if we don't get the vtable interface just right the first time? Or something comes along in the future that'd require core changes?

I'd consider something as simple as the BITMAP struct to be core-worthy. Do you have any idea how much that struct has changed throughout Allegro's development?

It's not a matter of something wrong. It's a matter of fixing incompatilibilities or adding, or removing redundant, functionality.

And see my edit in my previous post (you people post too fast )..

"Hey, I just found a way to add JPG2000 support!" "Cool! But we just released imgldrs version x.y with PNG support. Perhaps the next version." "Wait, didn't you just release core version x.y? I thought we were on imgldrs version a.b?" "No, we're on sndldrs version a.b. The core is version u.v and imgldrs is x.y." "Hey guys, what about my patch? "

Reading the manual doesn't take away from the fact that'll it'll still be a pain to keep track of everything.

You can only reliably keep track of what you use. Say you have a game working with core-4.3.5 and imgldrs-4.3.2. The user already has core-4.3.6, imgldrs-4.3.1, and sndldrs-4.3.3. Now you run the risk of updating his imgldrs, which is incompatible with his core. He can downgrade his core, but now it may be incompatible with his sndldrs.

Why would it have to be split to update to more modern times? You can internally split the code (eg. modularize) without creating multiple DLLs. Some things are already like this.

Unless the user happens to have core g.h, which may or may not be compatible. The only way to know that would be to test (ie. more work).

It was an example. Of course developers would be able toi keep better track of versions, but that doesn't mean it'd be a huge pain in the ass to keep track of (which is, after all, what we're trying to avoid).

What if the bugfix implies a vtable structure update? You can't be implying that vtable structures won't change..