Watching from the sidelines, it would seem we have run across a speed bump. It's good we ran into this problem sooner rather than later. However, there is a reason for debate, so I'm throwing my hat into the ring.
We have run into another impasse where two programming philosophies are at ends with each other. Getting down to the brass tacks, the problem is project management, which brings me into the picture.
I'm going to lay down the problem proper, and then offer a resolution. From this I would like comments on how to best implement the solution, so that everyone is happy.
Now I fancy myself as the ground layer. I come up with ideas on how implement Q-gears to the best of my ability. At the core, I'm a human resources guy, and don't like making decrees on high on what should and shouldn't be implemented without a lot of explanation on my part. I also am humbled by the fact that there are people who are willing to work on my silly idea and surprised by the support.
That being said.
Autoconf/Autotools stays, in all it's wretched, directory littering ugliness.
Sorry, that's how it is, any attempt to remove it will result in an immediate reversion on SVN to put it back.
Like I said, I'm not one to make decrees on high, but this issue is really non-negotiable. Now as opposed to just saying that this is how it is, and letting it be, I'm going to very carefully explain myself, and make the case for everyone here to understand.
Autotools, as it name implies, is a set of automatic tools to make a programmer's life a whole hell of a lot easier. It's also ugly as sin, but it's really a necessary evil. It's very critical part of cross-platfrom programming, and is a standard in software pre-configuration prior to compile-time. At the heart of Autotools is a macro language, called M4, which when used in conjunction with scripting, allows source code to become "aware" of it's surrounding environment. This allows the source code to *rewrite itself* in a way based on the computer it's been unpacked in.
For example, when you have autoconf set up in your application, a ./configire script will run a diagnostic on your computer system. It will check the Operating Syetem, CPU type, graphics abilities, installed libraries, and what ever else you think is critical to the application. From this system check, makefiles are generated *automatically* based on what kind of system it's on. There's no need to hand tweak library names, or to have to play "catch up" with the makefiles when something in the system's changed.
The issue at heart is this; Autotools is a very non-IDE way of doing cross-platform project management. It's ugly and harder than sin to work with if you don't understand what it's doing. The problem is that the system works for almost every platform. As opposed to fighting it, and calling it a blight on your code, you need to be *using* it. If it doesn't like spaces in your directory names, well then you need to change your directory names. If you don't like that it requires a file named "configure.h" when we already have a file named that which does something else, we need to rename our file to something else so autoconf can be used correctly.
Most every mature Linux application uses autotools, from glibc, to X, to gcc to the Linux kernel itself. Keep in mind that glibc and gcc are probably the most ported application in the entire Open Source ecosystem. That means something is being done correctly.
I do not want to have an IDE as a developmental dependency. (To program Q-Gears, you need Code::BLOCKS). That kind of thinking is ludicrous in the *NIX world. Using DevC++ is causing enough heartaches enough already. (Nothing against you choice in IDEs Akari, I'm sure it's a nice system). However, when I was a programmer once upon a time, my boss and I used nothing but "vi" to manage the codebase of an entire enterprise-level database system.
Now it's late, and I think I'm ranting. (If I am, I'm sorry, I will probably look at this tomorrow and pound my head on the table for writing all of this.)
Anyway, I open the thread on how best cooperate with our new found makefile making friend. I'm also open to criticism too. Keep in mind, autoconf can make windows makefiles too!