OSNews

I don't think so. Yes, the whole autotools compilation procedure is awfully hackish and better ones are available, but the compiler isn't a make system and should never be. Even things like Microsoft's .NET do have a build system, it's just that it's part of the IDE and it keeps track of dependencies and such.

Compilers and linkers need to remain separate from each other the build system for quite a lot of technical reasons.

1) People like to swap compilers, languages, etc. and link object files from different languages together. There's no way a single compiler could work all that out itself and manage it, calling other compilers and such.

2) Large programs have complicated things that need to be done during compilation, such as i18n and compiling modules into dynamic libraries, and so on. Usually for modularity, performance and memory reasons.

There are build systems that can do things like work out dependencies and module build orders and so on far better than autotools. The main thing preventing these from taking off is that there are standard ways of checking libraries provided for autotools (pkgconf files), but there is no ubiquitous standard for non-autotools build systems. Plus you can be practically certain that a GNU system set up for compiling has that build system installed.

For these other build systems to take off, there needs to be a *decent* standard created for library checking and such.

Also, another minor advantage of autotools based things is that the final output isn't dependent on autotools being installed. All of the pkg-conf stuff is "compiled" in a sense into a single ./configure shell script after autogen.sh (typically) is executed before distribution. Maybe others do this, I dunno.