Do you have interest in automake?

Do you have interest in automate? Like if you maintain a multi platform engine ...

Think DarkPlaces auto builds and I think FTE does this too.

[Trying to keep up with what DarkPlaces and FTE do is hard, at least MH tells us everything he does on his blog ( http://mhquake.blogspot.com ) ]

Autoconf and automake are horrible -- run, man, run fast away from them

Most projects which use them never really do it properly (because understanding how to do it properly is nigh impossible), and the configure scripts fail when you try to do something which is supposed to work out-of-the-box but was not expected and hence doesn't work (like using a cross-compiler).

Autoconf uses an obscure macro-processing language called 'm4', which in itself is quite neat, but here it adds an extra layer of complexity (and steepness of the learning curve) that really could have been avoided.

Scons is a better alternative (used by Doom3 code), we used that for a long time in a project and it got annoying after a while, it drives me crazy when the whole damn project has to be recompiled when I change a minor thing in a header file. Plus Scons is Python and that's when I discovered how much I hate whitespace-sensitive languages

Nowadays I just use normal Makefiles and I'm a lot happier.

On windows i agree on linux though it works quite well. Ofc you still need to learn how to use it.
For a cross build stay with IDE projects, its much easier to correct than autobuilds.
darkplaces uses a standard makefile as for FTE im not sure been a while.

fte just uses a recursive makefile. recursive makefiles might not be the fastest thing in the world, but its only windows that struggles with it, and most people use msvc on that platform anyway.
there's no ide integration with makefiles. oh well. I use vim in linux anyway.

autoconf is an additional layer of abstraction. if there's a difference between two versions of a library then you need to change your configure script just the same as you would your makefile, only now you need to learn m4 etc too. imho, its easier to write your own configure shell script instead of making some weird configure.in file and converting that to some really really really long and slow running configure shell script... Often you'll find that you don't actually need that anyway.

I don't have much interest in nightly builds myself because I tend to leave things in a semi-broken heap at the end of any given day. A nightly build setup would put me under self-inflicted pressure to have a working executable each day, which is something I can do without.

The blog is double-edged. I get to make an awful lot of stupid mistakes, and say an awful lot of daft things, in public. It's fun though and sometimes taking the time to just stop coding and write down what you're thinking can be a good way of working through some sticky issues.

Please, no. Just a makefile, thanks.

I used to ban autoconfs/automakes on my projects, since I was never able to compile them again on a freshly new PC.

So... I agree that using manual Makefile(s) are much clearer than those automistakes.

I suggest Cruisecontrol or Hudson for continuous integration.

Reading comments ... is thinking easier to make stable builds periodically and take a few minutes versus weeks of playing with text files.

The blog is double-edged. I get to make an awful lot of stupid mistakes, and say an awful lot of daft things, in public. It's fun though and sometimes taking the time to just stop coding and write down what you're thinking can be a good way of working through some sticky issues.

Perfection is rather boring. I prefer plot twists, the occasional dead-end mixed with occasional victories. Reading about setbacks or quirks makes the victories seem that much better. Plus adds character. Besides end result in DirectQ or whatever other tool or RMQ engine is always great.

I personally think casual observers don't realize how hard engine coding or mod making is. Getting exposed to some of it in a blog has an education factor. Versus those that realize that, say, a standardized tutorial for a commonly desired feature, a fix for a specific interpolation situation, or dynamic lighting is super-valuable.

Some casual observers think things get made automagically, but the real truth is that big advancement requires a metric ton of experimentation, planning, unforeseen aggravations and debugging.

The very important thing to know about GNU autotools is they are intended to make life easier for end users and distro packagers. They are not intended to be an ideal developer's toolkit and most every developer agrees they are a PITA. It is not necessary to master (or even know much about) the M4 stuff in order to construct autotools builds. It is not a case of "either/or" -- you can have both a "not-autotools" makefile for development and an autotools implementation for release packaging. Unfortunately, the official documentation is "opaque". Here are some references that are more accessible:

John Calcote. Autotools: A Practitioner’s Guild to GNU Autoconf, Automake, and LibTool.

Diego E. "Flameeyes" Petteno. Autotools Mythbuster http://www.flameeyes.eu/autotools-mythbuster

While many projects get autoconf and automake wrong, I find them very useful. My favorite autoconf feature is out-of-tree builds (keep source and build files completely separate), and for automake it's probably the autoconf integration and support for parallel builds (so long as you correctly specify non-automatic dependencies, automake always gets it right). Though it was somebody else that initially put autoconf into QuakeForge, I became QF's auto* guru. Since then, I've gotten the build system to sit up and beg or roll over on command .

Admittedly, things were a right mess back when there was a major change in autoconf, but I had QF's automake support working with a rather wide variety of automake versions (since dropped in favor of more modern features).

You can't pry automake even from my cold dead fingers. You'll have to wait till they turn to dust