Where Did SCons Come From and What Is Its Project History?

SCons started as ScCons, a build-tool design that won the Software Carpentry SC Build competition in August 2000. That design was itself based on an earlier software construction utility called Cons. The project was later renamed SCons, and it now lives at scons.org as an Open Source software construction tool.

The origin, step by step

The history on the official site is short and specific:

1. Cons came first. SCons's design was based on the Cons software construction utility.
2. ScCons won a competition. The ScCons build tool design won the Software Carpentry SC Build competition in August 2000.
3. The project was renamed. After that, the project became SCons.

So if you see the name "ScCons" in old references, it is the same lineage — not a separate, unrelated tool.

What SCons is, in the project's own terms

The site describes SCons as an Open Source software construction tool: an improved, cross-platform substitute for the classic Make utility, with integrated functionality similar to autoconf/automake and compiler caches such as ccache. The stated goal is an easier, more reliable and faster way to build software.

That framing matters for the history: SCons was not designed as a thin Make clone. It was positioned from the start as a replacement that folds in configuration and caching concerns that Make users usually bolt on separately.

What the project says makes it different

The site lists these as the reasons SCons is "better":

• Configuration files are Python scripts — you use a real programming language to solve build problems.
• Automatic dependency analysis built in for C, C++, and Fortran — no more make depend or make clean to get all dependencies.
• Extensible dependency analysis through user-defined dependency Scanners for other languages or file types.
• Built-in support for C, C++, D, Java, Fortran, Yacc, Lex, Qt, and SWIG, plus building TeX and LaTeX documents.
• Extensible builds through user-defined Builders for other languages or file types.
• Central repositories of source code and/or pre-built targets.
• Microsoft Visual Studio support, including generation of .dsp, .dsw, .sln, and .vcproj files.
• MD5 signatures for reliable detection of build changes, with optional, configurable support for traditional timestamps.
• Parallel builds — like make -j, but it keeps N jobs running simultaneously regardless of directory hierarchy.
• Autoconf-like support for finding #include files, libraries, functions, and typedefs.
• A global view of all dependencies — no multiple build passes or reordering targets.
• A shared cache for built files to speed up multiple builds — like ccache, but for any target file type, not just C/C++ compilation.
• Cross-platform by design, known to work on Linux, other POSIX systems (including AIX, BSD systems, HP/UX, IRIX, and Solaris), Windows 7/8/10, MacOS, and OS/2.

What the scons.org site is for

The site is the project's home. Its navigation points to the resources you would expect from an active Open Source project:

• Community
• Security
• Mailing Lists
• Contact
• Donate
• References
• Development (Developer's Guidelines, Bugs and Feature Requests)
• Documentation (Current Documentation, Frequently Asked Questions, Version-Specific Documentation)
• Logos
• Download
• Archives
• Releases
• News

If your question is "where do I get SCons or read its docs," those are the entry points. If your question is "who made it and why," the answer is the ScCons competition lineage above.

A quick way to place SCons among build tools

The practical takeaway: SCons's history explains its design. Because it grew out of a competition entry built on Cons, it inherited a "global dependency view" approach rather than Make's per-target, timestamp-driven model — which is why the project emphasizes automatic dependency analysis and Python-based configuration as its defining traits.