Either to the mailinglist (check the Allegro website for instructions, you need to subscribe), or Allegro's sourceforge tracker (probably the best option).

Hmm. It seems a lot of hassle for something that may never see the light of (release) day (no offence).
I'd recommend you provide patches for 4.3 and (possibly?) 4.9, but before working on 4.9 it's worthwhile to check if we really want a third build system (alongside SCons and CMake). Keeping two of them in sync is already a hassle, I'm not sure that providing a third will make things better - especially not if it needs changes to the layout of the filesystem (as you now and then seem to insist it does). Personally I'm not convinced it's worth the effort.

EDIT: I should point out, at least some of the developers (Peter, me, Elias?) get the development forum posts as e-mails as well, so in that sense you could already post the patch here and people should pick it up. Should, because for me all your posts seem to end up in my spambox.

Dead serious. I only saw this one because I checked here in between runs.

Any patch applied to SVN should leave the tree in a working state.
Also, just to make sure, the Windows (and DOS) builds are unaffected, right? What about OS X?

Did you test that on different architectures (32 and 64 bit)? Also when compiling with a magic main? On Linux and *BSD?

Thank you for your reply,

Existing things will remain untouched if you apply the patches I have sent. Even the old autotools support is not affected. The old configure.in and aclocal.m4 stay where they were. (only the new thing wouldn't work with ASM enabled)
And I don't have any clue about OSX, what was the current mean how to compile it? Could somebody post a typical build log?

Isn't the requirement of "always having working copy really working" little bit exaggerated? On the other hand, I can work little bit more on those patches so that they are more mature and comply with the requirement. Therefore I suggest not to apply them now. Applying the rename patch first looks smarter anyway.

The rename patch will (or at least really really should :-) leave everything in the same working state since only the filenames and records in all files are going to be changed.

Not yet, good point, I will try that tomorrow. I have to admit that I don't exactly know what tests should my autotools support pass. I have posted a dist archive here few posts earlier for people to test, but as I can see, guys here don't enjoy watching execution of configure scripts as much as I do...

I have tested it on 32bit Linux and Wine. AFAIK, the old autotools support did not support BSD and the new one supports mingw and Linux at this moment. What does 'compiling with a magic main' actually mean? I have used that magic main macro on Windows as well... Or is it something else?

Could you please explain why? Automake and libtool evolved quite much recently, so they are probably different from the old ones that you know...

Well, I hope that you are open for a discussion or to a possible change of opinion.
Let me react to your post:

This is true. But who cares. This is libtool's business. The libtool's 'supervising' of the compilation is also something that you don't have to worry about.

Libtool means goodbye to AM_PATH_ALLEGRO and the only cross-platform goodbye to allegro-config. I think that getting rid of those two is worth something.

It seems to be slow, but it is bash behind libtool that makes things slow OK, nobody cares whose fault it is. But it is really not a big issue for Allegro.

Makefiles.ams are even easier to understand, really. I have found autoconf to be much more complex and hard to use right than automake (the automake manual has half size). Once you tame autoconf, automake is like a gift for the effort.
The main allegro Makefile.am has three pages and it works for Unixes and for Windows. If you look at it and imagine some comments, it does not seem to be so hard to maintain (I attach it to this post. Editor that can do syntax highlighting is strongly advised ). If the autotools get accepted, I will write a complete documentation of the build system to the wiki.

I would like to be able to cross compile with allegro. I can't see any better mean how to achieve this than autotools.

I suggest that you keep your favourite build system as the main one and that you accept the autotoos one if it works and don't to worry about it.

autotools build system is able to work on unixes, OSX and Windows (MSYS). It is certainly more general than allegro-config

By "cross-compile with allegro" means that you have a program on Linux that uses allegro and you want to cross compile the program's, let's say, Windows version (= this is something else than cross-compiling allegro itself)
When one uses autotools, it is like ./configure --host i486-ming32 && make
The current solution involving allegro-config fails. pkg-config solution would also fail, by the way. Libtool can do that well.

Autotools are a standard on unixes and any cross-platform-and-unix library should provide some support for them to make the above possible for its users. This is the reason why it makes sense to have autotools build system supported. The current support of autotools is not transparent and does not allow cross compilation. I don't know what is the advantage of having both scons and cmake though...

I thought you said your build system didn't work on OS X?

allegro-config isn't a build system. It's a custom shell script that spits out compiler options on your current platform. It's as general as anyone wants it to be. That didn't answer my question though.

Of course that's what it means, what did you think I meant?

Yes. But for how much longer?
It won't go away, but the question is whether it'll be there as a legacy tool chain to support older applications or whether it'll be widely used by new applications.

There's two things that need to be kept separate here for clarity: offering support for other packages that use autotools to work with Allegro and being able to compile Allegro itself through autotools. One does not imply the other.
The first I think everyone can agree on (or made to agree on) is desirable; I have no idea how hard this is to do though, but maybe you can comment on that (giving a precise indication of what's needed). My understanding is that this is what allegro.m4 is for. The second one obviously not everyone can agree on.

Personally, I like being able to do "./configure && make && sudo make install" more than doing "mkdir Build; cd Build; cmake .. && make && sudo make install" for a number of reasons, one of them being I'm not as familiar with CMake and have trouble finding what I need if things don't work as they should. However, it does seem easy to get into. At the end of the day it doesn't matter much either way, because it's just a build system. The important thing is it works and is maintainable.

The cross compilation instructions in the manual don't work? This is a real question, I know they worked years ago when I last tried it.

Pretty much the same as having both CMake and autotools, I'd imagine.

Well, that's another thing, but I don't think Matěj is suggesting that Windows users be forced to use autotools, just that they'd have the option.

Well, true, we don't support any autotools-specific way to crosscompile your own games using Allegro, I didn't even know that was possible (and we don't even use autotools right now to cross-compile Allegro itself). (And who would use autotools to compile their game anyway? )

Can't wait until an equally committed person comes along advocating Ant/Jam/QMake/Cook/others, so that Allegro will have not one, not two, but every single build system there is.

CMake can cross-compile. CMake can make packages. Why not implement these features in CMake instead of adding a completely new build system for the very purpose of adding those features?

The cross compiler support is there, but just requires one long-ish option to activate:

cmake -DCMAKE_TOOLCHAIN_FILE=cmake/Toolchain-mingw.cmake .

I'd integrate it better into the CMake build, but as far as I know, there are no standards for cross compilers. We have to know where the root of the cross compile environment is, e.g. "/usr/local/cross-tools", and the name of the C and C++ compilers, e.g. "i386-mingw-gcc". And of course the target system, e.g. "Windows". I could make them all options, but it's probably easier just to edit the Toolchain-mingw.cmake file.

EDIT: actually, that would be too late. You really have to pass that on the command line.

How would you choose profiling or debug libraries? More .pc files?