Hello again, I would like to reopen discussion regarding Allegro interface (that is, headers)
AFAIK, hiding implementaion is a very smart practice for every library, not only multiplatform ones.
The current state of this in Allegro is not very nice: If you compile your code that uses Allegro, you have to tell Allegro which platform you use at that moment.
Although Allegro "does this for you", it is quite obscure.
If you take a look at allegro/internal/alconfig.h

 #if defined ALLEGRO_DJGPP
      #include "allegro/platform/aldjgpp.h"
 #if defined ...
      #include ...
//and so on...

Normally, you should pass -DALLEGRO_UNIX as CFLAGS on Unixes (includes Linux). You don't have to do that since the hand-written makefile adds a line containing this #define to allegro/platform/alplatf.h. You can imagine the cost of understanding and maintaining a build setup that has to perform such tricks.

When I have asked about this earlier, I received the following answer:

There is nothing wrong with it, but IMHO the multiplatform part of Allegro should be somehow separated from platform dependent part. I suggest not including those files by default and/or to force users to specify the appropriate CFLAGS manually if they need them. I don't think that many users use this. Then everybody would know whether it is easy or not to port his/her program to other platforms.
What are your opinions on this?

I have took a look on 4.9 in SVN and it seems to be pretty much the same. This affects allegro5 as well...

I think that they are included regardless if you want it or not... Am I wrong?

I don't agree if you mean that the user of Allegro has to include platform specific code in her/his programs. Otherwise there would be no way that that program would be multiplatform, don't you think?

You are not wrong, but you are missing the point nonetheless. Allegro has to include platform specific code, or it will not function.

I don't believe points 1 and 2 are true for the 4.9 branch any longer.

I think that if you take a look to allegro5/internal/alconfig.h, you may change your opinion.

No.

Stick to Allegro's platform independent API (ie, things not marked as "platform specific") and standard C library functions (of your favourite standard) and you're good. It's not more complicated than that.

That's because Allegro on platform X needs to know things about platform X, which means you may need some information stored in Allegro structures. For instance, a BITMAP struct on Windows may need to have a DirectX handle (or something equivalent), which doesn't exist or make sense in Linux (where you might have an X11 handle) or OS X. This is completely opaque to the user, however.

How?

If it ain't broken, don't fix it.

Matěj, if you want to help, please help us on the 4.9 branch. As X-G said, 4.2 development is closed. 4.3 development is mostly closed as well, but we are accepting code for new ports. 4.9 is what you should help with.

I agree that we shouldn't include platform-specific headers into user programs by default. This may not be possible in all cases, but it's something we should strive for. But breaking 4.2/4.3 now is just not on. Work on the 4.9 branch.

Actually I took a closer look and I can say that there is almost no platform dependent code in files that get included by default (files allegro5/platform/al*.h) There are rather some #defines that I don't quite understand. Is it really neccessary in Allegro5?

I haven't found any DX handle in BITMAP in those headers, is it possible?

However the file allegro5/internal/alconfig.h is ugly and things like

#if (defined ALLEGRO_DOS) || (defined ALLEGRO_WINDOWS)
   #define OTHER_PATH_SEPARATOR  '\\'
   #define DEVICE_SEPARATOR      ':'

should disappear and should be stored in the library itself (like char OTHER_PATH_SEPARATOR). This would even preserve compatibility.

I have thus found out that point 2 is invalid. Point 1 and 3 are undesirable and should be fixed if possible.

I would like to know whether you would be interested in such patches first. And then, I would like to know your opinions regarding how things could be fixed. And why they look like the way they look like

Regarding 4.9 vs 4.2: Things regarding build are extremely similar for 4.9 and 4.2. Since we use SVN, it make sense to fix everything with little bit bigger effort than to concentrate exclusively on 4.9...

Except that the we're using a completely different build system, yeah...

4.9 must not export any global vars.

I think you should look at the A5 API before making any further suggestions. Your comment about the 'screen' variable, as well as the allegro_init data structure suggestions show that you are ignorant of the fundamental differences between A5 and A4 in terms of their internal structure and operation.

Not really. 4.9 and 4.2 are very different. A change in 4,2 can not be directly applied to 4.9 at the moment.

Macro's can be #undef'ined.

What "screen"? There is no "screen" in Allegro 5 - and if there were, you'd have to get a pointer to it with al_get_screen().

Allegro 5's internal structure does have documentation on the wiki. While not complete, it should help