For SourceForge’s December “Community Choice” Project of the Month, the website’s community elected SCons, a software construction tool implemented in Python. In a wide-ranging interview, the SCons team shared their thoughts about the project’s history, purpose, and direction. To find programming jobs, click here. Tell me about the SCons project, please. Well, first, many thanks to the SourceForge community for choosing SCons as “Community Choice” Project of the Month! It’s an honor. SCons is a software construction tool (build tool, or make tool) implemented in Python, which uses Python scripts as “configuration files” for software builds. It is an easier, more reliable, and faster way to build software, solving a number of problems associated with other build tools, especially including the classic and ubiquitous make itself. Distinctive features of SCons include: a modular design that lends itself to being embedded in other applications; a global view of all dependencies in the source tree; an improved model for parallel (“-j”) builds; automatic scanning of files for dependencies; use of MD5 signatures for deciding whether a file is up-to-date; use of Python functions or objects to build target files; and easy user extensibility. Also, SCons is built with itself, using test-driven development with an extensive test suite. What made you start this? SCons has a direct predecessor named Cons, which was written in Perl. The original goal of Cons was to help scientists who are not experts in programming build their simulation codes and experiments in a reliable, friendly, and intuitive way, while being easy to extend to very complex builds. It used the same approach of specifying your build description in a full scripting language, but was programmed more in a monolithic fashion. For a user it wasn’t easy to extend the build system when he wanted to support a different kind of compiler, for example. And people, especially newcomers, didn’t really like Perl as a language that much. That’s when the idea of marrying the friendlier syntax of Python to the architectural advantages of Cons was born. The resulting merged design, at that time named ScCons, won the Software Carpentry build tool competition in 2000. CodeSourcery (by then the administrators of the competition) ultimately decided not to fund development of the build tool, but Steven Knight and several other contributors took the basic idea to the first SCons release on December 13, 2001. Has the original vision been achieved? A large number of open-source projects, companies, universities, and other scientific institutions use SCons as their build system, and are very happy with its stability and ease of maintenance. There are also several projects like Parts, PlatformIO, Madagascar, and FuDePAN, which use the SCons framework as a building block to provide highly specialized build environments to their users. So, we can say that the goal of delivering a stable, reliable and extensible tool that can be used for industrial-strength software builds has truly been met. Who can benefit the most from your project? Anybody who has to build something. Building here not only refers to the classic compilation of C/C++ files to programs and libraries, but also to creating PDF files from LaTeX documents, for example. If you have to create files from one or several sources, while correctly tracking the dependencies between those files, SCons is the right tool for the job. What is the need for this software development tool? Of course there are already many build systems out there. What makes SCons stand out from this crowd are two main points: 1. The ability to create large and complex builds in a single run, while correctly tracking all dependencies, and with full parallel support. 2. It’s easily extensible: Any user can override the default behavior of SCons to support different compilers/tools, or can change command-line options for their special build situation, without having to change the core sources. And they can wrap changes into a Python module, which can then be shared with colleagues and friends, or the users of an open-source project [who] want to build from source on their local machine. What’s the best way to get the most out of using SCons? There are basically two things: Learning yourself a little bit of Python, and understanding how SCons works differently from make, or any make file generators like CMake. The latter takes some time and we’re constantly trying to improve our documentation about this. What has your project team done to help build and nurture your community? One of the major steps was to migrate the code base away from SVN to a DVCS (Mercurial) to make source code contributions a lot easier. We also participated in the GSoC with several projects/students. Some members of the core team have given talks about SCons at various conferences. In general, we provide a lot of documentation about our workflows, branching strategies, documentation tool chain, and so on in our Wiki, so that interested users can find the information they need for a quick start. The most recent action item was to add SCons to the OpenHatch.org page and contribute a specialized tigris.org bugimporter as well. Have you all found that more frequent releases helps build up your community of users? Definitely. It helps give users confidence that the project is under active development. But even more than frequent releases, our community has grown because of switching from SVN to Mercurial. We now have many more people submitting really good work than ever before. What was the first big thing that happened for your project? Winning the Software Carpentry competition was a big early milestone that let us know there really was a need out there for a more flexible, extensible build tool. What helped make that happen? Steven Knight, the original author of SCons, worked tirelessly with the scientific computing community, which sponsored Software Carpentry. Without his efforts both as author and evangelist, SCons wouldn’t be where it is today. What was the net result for that event? It’s been a long fifteen years, but SCons is now a mature project, with thousands of downloads per week, dozens of contributors, and significant use throughout the software world. What is the next big thing for SCons? We have prepared some performance improvements (speedup/less memory) for the next two planned releases and will switch to a mixed Python 2/3 version after that. Also, we’re working on an improved way to specify tools and chains of tools. How long do you think that will take? Probably six months to a year. Do you have the resources you need to make that happen? Basically yes, but in an open-source project you can’t have too many contributors. Any helping hand is welcome! If you had it to do over again, what would you do differently for SCons? It would have been good to switch from SVN to hg much earlier, and, perhaps, also ditch the awkward backward compatibility to Python 1.5.x earlier. It would also be a big benefit to make it easier for third party add-on tools to work with SCons, by decoupling the core logic (nodes, taskmaster, signature etc.) from the tools. Why? Moving to a DVCS has really expanded our ability to attract contributors. Similarly, dropping support for ancient Python versions gives developers more tools to work with and makes it easier to contribute. And decoupling tools from the core would hopefully have the same effect. Any reason you can’t do that now? Well, we did most of that. Now, we have new challenges ahead of us. Is there anything else we should know? We try to be an open, supportive, and helpful community. Check out our website, download SCons from SourceForge, and sign up for our mailing list.

Related Articles

• SourceForge Interview: A New Game Engine
• SourceForge Interview: Enterprise Social Collaboration
• SourceForge Interview: CMDBuild

Image: Trifonenko Ivan. Orsk/Shutterstock.com