I would suggest you not bother, and just grab the latest binaries off of http://www.allegro5.org

If you're hell bent on compiling yourself, try the latest allegro 4.9, it should be somewhat easier to get built.

I think the real question is why the A5 devs made A5 so complicated...they could have simply included all the code and create one simple library to use.

Is it 'library size'? nope, it is not. In this day and age, it does not matter if a library is a few hundred KBs more than usual.

Is it 'ease of use'? nope, it is not. A4 is a hell of a lot more easier to use (not the API, the library; the A5 API is superior in every way).

Is it 'bloat'? nope, it is not. A4 includes a ton of 'add ons', but no one (that I know of) ever complained about them. If you don't like A4 extra things, then don't use them. A5 should have been the same.

Is there any real reason why drawing primitive is an add on? there is not. Is there any real reason why audio is an add on? again, there is not. As if games don't need sound...one might say that the A5 audio add on could be easily replaced with other add ons. I would say to them that it would hurt nobody to have the add on in the library, and if someone did not want to use it, then he would not have to do so. Same goes with all the other 'add ons', which provide essential functionality in reality...

Anyway, enough ranting. In the end, I guess I should be grateful that there is Allegro (which I am)...

Personally I was not persuaded. They talked about bloat, increased library size, ease of use etc none of which are valid excuses.

Please explain to us why.

EDIT:

For example, in this thread, they present the following reasons for the add ons:

1) bloat. The word itself is meaningless. Bloat in what? library size? it does not matter in this day and age. Bloat for the programmer? a well-organized documentation alleviates that. So bloat it is not.

2) "Pulling in external dependencies is another". Yeap, it is left on us A5 users to pull in the extra dependencies.

3) "Modularity: we try to not use too many library internals inside addons, which improves understandability, maintainability and confirms our designs". The developers of the library put the burden on the users of the library.

4) "You can choose to not use any addon that you feel is inadequate, e.g. some people require a more advanced audio library than we provide". Nothing stops people from using another sound library, if so desired.

5) "Also, we like to trip up newbies" i.e. "I run out of excuses, I might say something silly to cover up the lame excuses for the A5 add ons".

So far, not a single valid argument in favor of addons. Perhaps there are other issues (licensing, for example), that I am unaware of. Please enlighten us.

Are you complaining about addons, or external dependencies?

To begin, Allegro 4 also had addons (AllegroGL, alogg, aljpeg(sp?) the truetype one, etc), and those also require dependencies. The only difference is that they weren't bundled with A4 and are bundled with A4.9, making them easier to obtain (single download) and more likely to function (API changes are fixed by the people who make those API changes). Overall, the convenience to the user and the addon developer is increased relative to A4.

Then, there's the linkage issues... I honestly don't mind it. I set up my IDE to link the proper addons (or perhaps make a CMakeLists.txt thing) and forget about it. Again, this is unchanged from A4. Perhaps we could make it better by making addons be a part of the core library, but there's really no point. Once A4.9 stabilizes (or even now!) we could make templates for projects for the various IDE's if it's so desired.

In terms of addon proliferation (you mentioned the primitives addon) then yeah, perhaps you have a point. It takes you 15 more seconds to write in the addon library in the link line. I don't see the major issue here. Maybe some addons shouldn't be addons, but it's a purely syntactical issue... there are no real practical differences in terms of ease of use.

So, overall, things have improved relative to A4 in terms of library usage.

I've never done that.

I already said:

I don't have the time to dig into the licensing issues, but I don't think it's a problem. Since Allegro is open source, the delicate flavor of open source that Allegro is can be changed to fit with the open source licenses of the libraries it uses.

I still don't see the problem. Please tell me where the problem is with linking to those libraries. Is it a matter of memory usage? where exactly is the bloat?

Is the problem to specify linking with the given libraries? big deal. From what I know so far, Allegro 4 provides a linker options string, so all you have to do is do the same with A5.

I agree that some people will not want to link with said libraries, but 95% of Allegro users will do want to link with those libraries. So by providing the libs as addons, you are doing a service to the 5% of the A5 users that will choose to use other libs, while the 95% of the users will have to suffer through it.

I agree, but I don't see how if these addons are part of the library limits your choices. You can still link with any lib you want.

Please justify your argument with some facts.

A few KBs more in the link tables of the process is a negligible overhead.

No, it's not the same. With plain A4 and no addons, I have audio, color, font (not truetype), image I/O, filesystem and drawing support out of the box. With A5, I don't have those functions out of the box. Each time I want to make a simple test program in order to learn A5, I will have to specify over and over the same libraries.

It also makes the building process difficult. It's not a coincidence that many people have problems with building A5.

You have to do it again and again though for every new project. It's not "forget about it".

That doesn't solve the compilation issues. At least there are some people offering a precompiled A5 lib with all the addons compiled into them.

Is there a point to not be able to draw with a multimedia library? I don't think there is.

No, it takes a lot more than that. It's not one addon, there are at least 4 addons that will be used again and again in every project. There are also issues when moving things around and tidying up the files, updating libs etc.

No. With A4, you simply had to link with alleg.lib and all the desired functionality was present for 99% of cases. With A5, you have to spent time configuring your project, choosing addons, remembering those lib names, including the right files, etc.

That's very subjective. For me the functionality of playing OGG's and loading PNG's is always the desired functionality, that I would not be able to get in A4 without hunting down the off-site addons, not so in A4.9. In terms of linkage, the processes are identical.

You do have a point if you only wanted to play WAV files and load TGA images though.

Maybe A4.9 requires a little bit more effort to set up versus A4, making it unsuitable for something like Minorhack (very maybe, as it takes me less than a minute to start up a simple A4.9 application from scratch). For anything longer, you will want to be using the modern file formats with A4.9 allows you to use with ease (relative to A4) and the initial set up cost will be negligible to the time saved from using the superior API.

Perhaps it would please you to modify the allegro5-config script to have an 'all' option, that links all the possible addons? That'll remove all your linking complaints (at least on Linux, I've no idea if something like that is possible under Windows). I believe you can provide a pkg-config function to do the same too, if you don't like the custom script. We can even provide a header that includes all of the allegro5 headers!

Even if we don't, you can make them yourself One time investment that will pay huge dividends in the future.

It'll also make incompatible libraries afaik. Do you REALLY want to support that? People will come in and complain about it.

Its more like a few hundred KB of extra memory and dlls. Once you link to a lib, you are forced to ship it. Do you want to ship your game with 12 DLLs you're not going to use at all?

Windows, you have to do the work that pkg-config or allegro-config would do for you. Static linking is a pain because of this.

If you remember the lib and include names by heart, then it's ok I suppose.

It would certainly be good to have an 'all' option, especially since Allegro attracts a lot of inexperienced people.

No, but simple things should be kept simple. I like the option mentioned above by Siegelord, and I think that's the best way to go.

Then another way should be found to achieve the same result.

Indeed. But it is even simpler to have the most-often used functionality in one library.