The difference is in the addons.

Personally, I just don't have the time, but feel free to post a realistic workable example of what you have in mind (a vague "change stuff" or very radical design changes without a clear advantage are not likely to be greeted with a great deal of enthusiasm )

I think we tend to disagree a bit on what is simpler or "standard".

There used to be IRC meetings regularly, I think they're public so you should be able to join one of those if they're still held (I never joined in on any of those).

And I know that some here think the same about SConstruct.. so I guess in the end, we'll have to pick the lesser of 3 evils

That's true (except the statement that autotools are a failure :-). But the only thing you have to do in order to ./configure && make && make install on w32 is to... install MSYS and MinGW. If you do that, the rest is a peace of cake that everybody loves (Don't tell me that you don't like that configure script reports and the ablility to configure anything!)

The worst part is that the autotools suite is entirely obsolete now that we have SCons; and I don't just mean Allegro, I mean everyone. I see no compelling reason to use autotools anymore.

At least one of those is actually an established language (and thus a lot more flexible and easy to get help with).

Dear friends,
I have just completed the autotools support for Allegro 4.2.3
It compiles under Linux and it cross-compiles to Windows (with ASM off) if one has mingw and friends.
It passes 'make distcheck', which took quite a lot of work, but now it really supports VPATH builds and read-only source trees, which is cool if one needs it.
The autotools resource files were simplified and beautified, so I think that there won't be any complaints about aesthetic qualities of configure.ac or Makefile.ams. It looks really beautiful if you have a right editor with the right syntax highlighting! (my favourite one is Vim)
Anyway, I attach the checked distribution. I encourage to test it if you can and if there aren't be any complaints, I am going to send patches.
I will also update the wiki page so that everybody can see the advantages of this setup.
As usually, there are some technical details that need to be discussed
(for instance: Library versioning, some program's source code regarding datafiles etc., but that can wait)

So check out the attachement!

We really should do a 4.4.0 release though - and the main issue stopping that so far was build problems (under OSX). No idea if the new autotools build makes it any easier though..

What needs done for 4.4? Do we even know?

What did you say? How come! Why you haven't told me earlier?! So much of work in vain... AARGH!

Oh wait, now I recall... Someone told me earlier, but I have thought that it was some naive newbie

Actually it would be cool if you take a look at it. Then I can submit patches to SVN and start working on support for 4.3+. Since those two setups are going to be extremely similar, it will be highly beneficial if unix users take a look at it.

The most notable changes I have made is introducing of three new directories (for build only):
/build-bin (examples, demo and tools build there),
/build-lib (can be /lib, but I would like to get some makefiles there and I am not sure whether this wouldn't upset somebody) and
/data (Makefiles that care about distribution of datafiles are there. In the future, some Allegro artwork such as wallpapers, logos etc. can go there. pkg-config support lives there as well)

Neither I have a Mac, but of course it should be much better with Autotools

Which one of the developers did you think was a newbie? Peter, Elias, or Evert?

See that we can do. The autotools build for 4.3/4.4 is a mess, and we still intend on supporting autotools for it, unless the cmake and scons guys for 4.9/5.0 decide to redo their build scripts for 4.3 (which I doubt ).

I've looked at it a little, and it does seem more organized than the old setup.

Wait, did you say you already have pkg-config support? Can you make a pkg-config setup for 4.9? Pretty please? Basically what we need for 4.9 is a main pkg-config config for the base lib, and one each for each addon. At least I assume thats the best way to set it up. We should be-able to get rid of allegro-config that way.

Did you do an out-of-source build? Did you copy the DLLs into place? And the data directory for examples?

Muhaha, finally something that seem to interest you! If you condemn scons and cmake, worship autotools, re-introduce global screen pointer to Allegro5 and release it as 4.2.4 release, you can have it

Unfortunatelly pkg-config is not very suitable for cross-platform libraries. It can do its job for people that are not interested in cross-compilation. Libtool is much better in this, trust me. Luckily, both can be supported at the same time.

allegro-config is evil and so is AM_PATH_ALLEGRO. They actually do quite a good job if you are not into cross-compilation, but maintaining them is obviously a nightmare.

Second thing, you can use custom compilers. I have tried the intel compiler (you just have to write CC=icc ./configure --disable-asm). It compiles, but it always crashes somewhere. Any hackers here have icc as their compiler of choice?

Those were actually jokes, as well as the one about 'naive newbies'. I hope that nobody took that seriously

Seems that nobody has any suggestions at the moment. Who should I send patches to?
The autotools setup for 4.2 branch (almost) absolutelly requires renaming *.s ASM files to *.S It should be accepted since it is a really, really pure internal thing and if all the filenames in makefiles and file lists are renamed as well, nobody will notice, right?