In the case of the examples you cited, the IDE was the build system. In most cases you were using libraries that shipped with the development tools, so it appea

In the case of the examples you cited, the IDE was the build system. In most cases you were using libraries that shipped with the development tools, so it appeared to be easy to manage since everything was done for you. Using third-party libraries wasn't too bad either. It typically involved changing a couple of parameters in the IDE. From my limited experience with Visual Studio, the same can be said of it. Much the same can be said of simple Makefiles. If you are targeting your own machine, you can create a couple of variables to track libraries and such then tweak them much as you would tweak the configuration of a traditional IDE. The trouble comes with creating software that other people will build or while building software created by other people. Linux (actually, Unix in general) is notorious for its inconsistencies: libraries and headers aren't always in the same place, sometimes libraries are missing, sometimes one library is used in the place of another. Tools like autoconf help developers to work around that. Of course, modern build systems go a step further by pulling in dependencies. It probably wouldn't be much of an issue, except for one thing: everyone seems to have their pet build system.