Not a practical question as such, but what exactly is the point of a ./configure script?

I mean surely if the right headers and libraries are not present the compiler will just throw a readable error anyway, so what good does it do for configure to do this?

Checks for dependencies, check paths, and creates the make file. Without it, well, I'd probably guess your install would fail each time.

I'm not convinced, of the things you mentioned the only thing a 'make' can't do is write the makefile.

source files are non system/distro specific. ./configure configures the makefile for your system/distro. Without doing this, the make file would not work.

Okay.. let me use a different word, it prepares make before making the makefile, etc.

You know, when you run ./configure, it should spit out characters and numbers and such on your screen, it actually is telling you there what its doing.

An easy way to convince yourself would be to try write a Makefile that will compile
the same program on multiple operating systems and accross many different architectures.
Also try to get a makefile to generate those .moc files used in Qt KDE compilations
across different operating systems and architectures.
Also your Makefile will have to take command line args to set various programs feature sets and default pathways so the user can cantroll how the program functions.
Some of the Unix guys don't use configure but they write a million Makefiles and you pick the one that works for you -- somehow that doesn't seem better.

hmm I see your point, but changing the architecture is a very simple process isn't it? Just change a compiler switch.

I see how it would be difficult to get code to compile on multiple OS's though.

I'm not really qualified to be discussing this but crosscompiling i think involves both compilng and linking against different than the native core libraries...
the whole configure thing is automated and is to help developers spend time writing programms rather than Makefiles -- the configure script itself is generated by autoconf based on a script generated by automake. configure can even be setup to generate the spec files for package managers.
I mean yea the Makefile is all just compiler commands ultimately you just have to get them into the Makefile somehow along with the other stuff your package needs to compile..
People for instance build Linux with different directory structures so you sometimes have to ask where things are and many libraries keep track of where their header files are installed in case configure asks..
If there are some platform specific defines (MACROS) you need to use as a workaround for something they are generated by config in config.h that becomes a part of the programs header files.
Autoheader takes as input the files acconfig.h and generates the config.h.in template by parsing configure.in.
then config turns config.h.in into config.h.
configure now rather than just checking for the needed symbols presence in the libs header files will actually go and check for the needed symbol in the library itself. and can check for functions within the std c lib.
to make sure they are present so your newly compiled programm will actually run.
libtool can keep track of the extent of backward compatability in a certain library.
and of course like i said earlier configure allows you to install things in unorthodox places with different config file locations or using external rather than internal libraries of even do a total static linkage disable some functionality you don't like or whatever.

for a look at a non-configure alternative check out the cdrtools package
i have looked at that Makefile system for hours and have no idea how it works

Sounds like fun... But if you seriously think writing a makefile is any more hassle than all that, you're nuts.

So configure gives a nice readable output, but wheres the fun then?

Personally, I would rather have configure tell me I need libfoo >= 2.42.493, rather than start a make, leave, come back 5 hours later, and find out it failed after 5 minutes with some obscure error message which may or may not be because I need to upgrade libfoo.