Software builds are a core part of the software development lifecycle. Builds are where source files are converted into executable software products. The classic tool for automating software builds is the Unix "make" program, which was invented around 1974 to reduce software build times for C programs on the new Unix operating system. Make programs decide whether source files need rebuilding based by using text Makefiles that contain dependency trees, and by comparing timestamps on source files and object files. Beginning in the 1980s, integrated development environments (IDEs) began to do software builds of IDE "project files" themselves, reducing the need for people to write traditional makefiles for software builds of IDE projects. However, makefiles are still very useful for software build operations that go beyond individual IDE projects, and so many modern IDEs generate external makefiles for IDE projects. Around the turn of the millennium (2000), a new generation of build manager tools began to emerge, as people tried to solve the still-present problem of software builds using interactive GUI interface technologies developed in the 1990s. The trend of developing software on personal computers under Windows played a big part in motivating the new generation of GUI-interface tools, since the Windows world was a GUI world, unlike previous decades of Unix systems. This new generation of GUI-oriented tools helped people to interactively script and manage build processes using a GUI interface, rather than using traditional makefiles. Instead of coding lines in a troublesome makefile syntax, people could "code" the steps of their build process using more friendly GUI dialog boxes, and could click to execute various steps in the build process. Especially for individual programmers, these tools proved quite useful. Some of the essential goals of a build manager tool are to provide a nicer GUI interface for people, to provide a more friendly way of specifying build process steps, and to provide additional functionality and interactive build management convenience through the interface. But build manager tools do not typically address the deeper problems of larger-scale builds that involve multiple languages, larger numbers of files and platforms and components, pervasive parallelism and distribution over remote machines, or other complex aspects of scalable builds. For this kind of problem, build management _systems_ are required. Build management systems try to go beyond simple build scripting tools, by providing more general software build models that involve some level of abstraction away from the details of software builds. For example, a build system might provide a layer of abstraction above the traditional makefile layer, leading to platform-independent makefiles (or equivalents). Or a build management system might abstract builds even further, by calculating and executing multiplatform build sequences for itself, in a totally automated way, thereby reducing the need for people to be involved in scripting their builds at all.
Thanks to DMOZ, which built a great web directory for nearly two decades and freely shared it with the web. About us