Let's talk about portability.  As we all know, there are some differences
between operating systems.  Most operating systems follow the POSIX standard,
but there are always some platform specific differences-- a missing header file
here, a nonstandard libc function there, and so forth.<p>

Build systems can't just wave a magic wand and make these differences
disappear.  The programmer is still responsible for implementing workarounds
for things that are missing, and being aware of specific limitations that a
given operating system may have.  For example, older versions of Linux using
the ext3 filesystem could only have 16,384 subdirectories in a directory.
There is nothing that the build system can do to insulate programmers from this
reality.<p>

So, in a very real sense, build systems can only make portability worse, but
never better.  How can a build system make portability worse?  
<ul>
  <li>It can rely on notoriously unportable contructs like shell scripts.</li>
  <li>It can fail to support widely used platforms.</li>
  <li>Through a lack of abstraction, it can needlessly expose details of the
  underlying platform to the developer.</li>
</ul><p>

autotools does all three of these things.  You end up writing snippets of shell
scripts in configure.ac, Makefile.am, and other files.  These scripts may work
fine on your own platform when using your version of Bash, but they tend to
fail on other platforms.<p>