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?

... why are you proposing changes to a codebase that is never going to change? (All active developmnent is in 4.9. Comment on that instead.)

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

If you use Allegro's standard API, it will be easy to port to other platforms. If you use the platform specific API that is obtained only if you include those platform specific headers, then it will be hard to port to other platforms. I don't see where the confusion is.

You do realize that Allegro is multi-platform by the very virtue of it having equivalent implementations for its API for every platform? There will always be a need to include platform specific code. As long as you don't override that process via including headers on your own, though, your program will remain cross platform because Allegro will automagically determine which platform specific headers to include on any given platform. Why do you wish for this to be the responsibility of the user?

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?

He meant that Allegro's code will always have to have platform-specific code.

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

Hm, I was not concerned about internal Allegro structure, but rather about library interface for users.

I sum my ideas in this list:
1. Allegro user interface includes platform specific headers by default.
2. Point 1 implies that user can write platform-specific code without being clearly aware of that... [EDIT: This is not really true ]
3. The current situation is obscure, there are many #defines all over the place + you have to generate allegro/platform/alplatf.h

What do you think?

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

The library interface for users is fine.

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

I didn't need to. I tried to put some platform specific code into my program, and it failed to compile. That's good enough for me.

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.

And since you have to recompile your program just to get a binary that will work on a given platform, there is no issue. You have to recompile anyway.

As Evert said, so long as you stick to language standard functions, and allegro's non platform specific functions, you'll be fine, and your program can be compiled and run on any platform it happens to directly support.

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.

In addition to what Peter said, please contribute patches for 4.9 rather than point out what should be changed and how.
(I know you're willing to provide them, just making sure).

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...

Not if theres never going to be another release based on 4.2 it doesn't. And we have very limited resources, getting 5 finished up is taking what little time we all have.

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

4.9 must not export any global vars.

How come? Now Allegro #defines macros... And 'screen' is not a global var?
When I think about it, following thoughts how this can be solved in another way come to my mind:
1. Export constants (constants are not variables, right? :-)
2. Make library functions that return those platform specific data.
3. Make allegro_init to return some structure that would contain all the data
4. Generate ONE header during (or just before) compilation that has the same name on all platforms (this would at least kill those #ifdef somesystem #include somefile things)

I just have to solve a minor difficulty with modules under Unix and then I will be able to send a patch that brings that new level of autotools experience to 4.2

Then it can be svn copied to another branches where it will require only small modifications in order to work well.

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.

How many times do you have to be told before it gets through to you? Allegro 4.2 isn't going to change. Look at future versions.

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().

Are we still discussing the point of build setup fans? For instance, I have noticed that Allegro5 even uses modules...
I mean, this can't be sooo different, you always end up generating a header, checking for stuff and finally doing some compiling/linking and docs generation...

And when I took a look on CMakeLists.txt, I just wonder who said that autotools are arcane and ugly etc.

Regarding the current header situation, don't you consider making some brainstorming on how to improve it? I think that it is clear that it can and should be improved and the question is how to do that in the smartest way. You guys know Allegro5 better than me and maybe I am more inspired by 'standards' and simplicity; and it would be great if these two qualities could somehow work together for the benefit of Allegro and its users. There are more things to improve, so we can make some sort of 10 minutes "IRC brainstorming" among people that feel interested in this. I can post the results to the wiki afterwards so that everybody will be able make suggestions or learn on how things are...

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

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).

They are usually held once a month, but people don't always show up or have anything to talk about most recently. Most of the stuff that needed group consensus and brain storming has been done. A lot of whats left is documentation and actually testing it all to make sure it all works now.

That reminds me, we need some form of test suite. I have NO idea what software we should use, or if we should roll our own, or what type of testing methodology we should use... But we do need something. At least where we can test stuff reliably.

Oh and the filesystem functions need to handle unicode properly so the OS gets what it needs, without mangling of the chars... So some stuff left to do...

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

(One of) the main reason(s) why autotools is a pile of failure is that it's difficult and annoying to make it work on win32, and it simply won't work natively no matter what.

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!)

automake and friends are too ugly and annoying to work with, and the configure scripts run too damn slow. Thats my entire opinion.

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.

I dunno, from what I've seen Scons isn't any better. Its just some hacked up setup using python. Big deal. M4? Python? Same story.

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

Unless you detest Python, that is.

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!

There may never be another 4.2 release, you understand that right?

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..

Ya. I say we release 4.9.7 and 4.4.0 at the same time, if possible. I don't have a mac though, so I don't know how realistic that is.

What needs done for 4.4? Do we even know?

The todo lists on the wiki are for 4.9 and 4.2 (outdated).. I think the only thing holding it up was the macosx port.

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

You were told three times in this thread alone. Including by one of the developers.

Gee, I wonder who looks like a naive newbie now.

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.

I'm not impressed with the new build system either, it is all but impossible to compile for MSVC with it. And when I finally did get my hands on a build, nothing worked anyhow (and it wasn't a debug build, so I couldn't see what was happening).

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

I used binaries provided by another user here on a.cc. DLLs were all in, program would run but then just crash. First crash was due to me not having the data directory in place (when compiling the example in debug mode, the crash was happening within allegro when trying to load the bitmap that didn't exist, which seemed real nice), then after putting it in it just randomly crashed. I can't really give any useful info because I don't have a debug build of the library and, frankly, I don't have the time to mess around trying to get it to build at the moment (too much school work).

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?

Sure. When hell freezes over.

They're not even API compatible, leave alone ABI compatible.

I don't think allegro-config is supposed to be used for cross compilation.

You always could.

I think it worked the last time I tried it, which is a couple of years ago. I may have had to use a couple of special compiler switches to make it work though, I don't remember.
I think I had some problems with crashes somewhere in draw_character() (or some such) and recompiling that file alone with gcc things worked properly. There may be something in the mailinglist archives about this, have a look there.

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?

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.

Still in no offence mode, right?

I attach the autofiles patch. Then the demo patch (it adds a possibility to define datafile location during compilation and it is backward compatible).

It will not work due to asm files that need to be renamed. I already have a script that can generate the patch that svn renames those files and changes according filenames inside files at once. Nothing to worry about even more if you are not planning to release another 4.2 release.

I will generate the patch after you apply the autofiles one since the Makefile.ams need some renaming as well..

And finally, there is no allegro_unsharable library now and it seems to work well... Again no issue to 4.3+

Comments are always welcomed, of course!

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?

Just so we're clear, I will not accept any patch using automake.

Even more so if it uses libtool.

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?

If existing builds are unaffected, so too will be OS X.

No. No single commit should break the trunk. Of course it still happens now and then by accident.
If you like, that's what you get for providing a patch for a deadlocked feature-frozen branch. Do take note of Peter's post if you haven't already.

Fine.

It should build the library in a state that is ABI compatible with other 4.2 libraries. From what I recall, there are subtle differences between 32 bit and 64 bit AMD/Intel architectures. Not needing allegro-unsharable is nice, but make sure you really don't need it anywhere, ever.

Since when?

It means you have a magic main, or in other words, END_OF_MAIN() actually does something. This is always the case on Windows and OS X, and it may be the case on *NIX.

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

Perhaps. But I have enough bad experiences, especially with libtool which puts things in hidden directories and wants total control of your command line. When it breaks (and it does break) it's not easy to recover because it's not transparent. Not to mention, libtool is extremely slow. Automake is not necessary. Makefiles are easy to understand, automake just adds another layer of autogenerated crud that gets in the way whenever you want to make a change or do something unusual.

Further, it's a maintenance issue. When you lose interest (and you will), who will maintain this? Everybody knows make, and we can manage autoconf well enough (not expertly, but well enough).

It's just not on to require developers to work with build tools they despise. The primary build system for Allegro 5 will be CMake. Too bad if you don't like it. It's just a build system. End users deal with the build system roughly once per release. Developers have to deal with it every time they touch the code. Therefore, developer opinions win.

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.

allegro-config is used on *nix ad OS X (technically a UNIX too, but we'll make the distinction anyway) - in other words, everywhere except Windows and DOS. Your build system isn't that general. Besides,

I don't see the point. Really. What's your problem with allegro-config anyway?
I don't have an opinion on AM_PATH_ALLEGRO, since I'm only half sure of what it is and what it'd be useful for.

Err... CMake?
I think Peter does this to test the Windows port through Wine.

That's the point he was trying to make: if it works now there is no guarantee it'll stay that way. Right now, whenever I make a change to the CMake build system, someone has to fix the SCons system to make sure they're still compatible. That's already a hassle. Can you really see someone taking on a third build system? What's stopping us from having a dozen others as well?

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...

That's what everyone means, it works with Allegro 4.3.x makefiles as well as cmake in 4.9.x.

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.

Please note, not everyone using Allegro on Windows will want to install MSYS. Outside of cross-compiling, autotools and Windows don't mix. Also, you need to deal with the MSVC users as well. You going to tell them to install MSYS just to make a VC project file? And these people may be the types who don't even know what a command prompt is.

CMake seems to be the best tool for handling generating the make/project files on Windows from what I seen (there's qmake as well which is for Trolltect's QT BTW, it works nicely as well).

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.

I hope that this is your question that I have lost :-)
allegro-config is not an elegant solution today. For instance, if you have multiple allegros installed, it is of no use AFAIK.
1. pkg-config can do the same in much more elegant way
2. libtool can do more than that in an even more elegant way.

I am sorry, but I don't understand. I can't see what allegro makefiles have to do with cross-compiling my program. Basically, the problem is: What should I tell to the linker?

It does not work now, but it has a good potential to work there.

You are right. One transition is significantly easier than the other one, though

I haven't found any specific cross-compiling instructions in allegro42 manual so far. I have found mingw instructions that mention cross-compilation, but no mention of autotools support there.

Well, maybe from your point of view. But distribution packagers will have much easier job with autotools. And you can also do 'make distcheck' that does the package without unnecessary files + lots of tests for you...

The main question for me is whether automake + libtool can make it into the repository. I think that those tools should be given a chance on 4.2 and 4.3 branches. Then all of you can come and see whether it bites or not or whether it is really not maintainable.

2MiquelFire: Don't worry now, it will come in the second wave (joke)

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? )

Come on, I would use autotools even for hello world!
But there are another projects that may benefit from that. Don't forget that adding autotools support for projects using allegro is really trivial since they usually depend ONLY on allegro!
Anyway, take a look here: http://garden.sourceforge.net/
Providing some bulletproof autotools support would allow making binary releases or packages for all sorts of platforms with an absolutelly minimal effort.

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?

I hope thats a joke. Autotools adds nearly a megabyte of overhead to any project its added to.

The only feature the Cmake build setup doesn't have yet is proper cross compiling, but I don't think its that hard to setup, just tell it to make mingw make files, and set CC to the mingw cross compiler. If that doesn't work, it probably only needs a little bit of work.

The one thing that I would like to see added to allegro is pkg-config support. That would give us instant support of more than one OpenSource IDE. Allegro would show up as a library in a list in the IDE that people can choose from, and it'd all "just work"&tm;

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.

Here's how taglib does it (it's some KDE library). If we need more dependencies we can find paths to them via CMake functions for that I'd imagine.

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/taglib_c.pc.cmake ${CMAKE_CURRENT_BINARY_DIR}/taglib_c.pc )

#Later...

INSTALL( FILES  ${CMAKE_CURRENT_BINARY_DIR}/taglib_c.pc DESTINATION ${LIB_INSTALL_DIR}/pkgconfig)

Where taglib_c.pc.cmake contains:

prefix=${CMAKE_INSTALL_PREFIX}
exec_prefix=${CMAKE_INSTALL_PREFIX}
libdir=${LIB_INSTALL_DIR}
includedir=${INCLUDE_INSTALL_DIR}


Name: TagLib C Bindings
Description: Audio meta-data library (C bindings)
Requires: taglib
Version: ${TAGLIB_LIB_MAJOR_VERSION}.${TAGLIB_LIB_MINOR_VERSION}.${TAGLIB_LIB_PATCH_VERSION}
Libs: -L${LIB_INSTALL_DIR} -ltag_c
Cflags: -I=${INCLUDE_INSTALL_DIR}/taglib

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

I'd imagine so, yes. I can't seem to find an example of such a library that has these different versions to confirm that though.