SCons is actively looking for contributors. You can contribute to the code of SCons itself, the documentation, the examples/ cookbook, and more. If you're interested, we'd love to hear from you at email@example.com.
It's only fair that you get an idea of how we develop SCons before deciding if you'd like to help. There is a complete and evolving set of Developer's Guidelines that go into reasonable detail about how we're guaranteeing that SCons is always an exceptionally stable and reliable tool for building software. Here are two key points:
- We write a lot of automated tests to test thoroughly test SCons. Lines of test code currently outnumber lines of code in SCons itself by about 3:1.
- You can use git (via github) as a front end for submitting patches.
Please take a look at the complete guidelines before deciding to hop on board.
That said, here are resources for SCons developers (or onlookers):
The complete statement of guiding principles and procedures for SCons development. Subject to change and improvement.
The SCons project page at GitHub. This is the center of active SCons development, hosting the issue tracker (bugs, patches, tasks, etc.).
The SCons project page at SourceForge. This is where we used to host development, but no longer. It's now mostly of historic interest, although it's also the origination site for downloads.
Archive of the latest checked-in source in a couple of formats.
Updated whenever a an SCons release is made.
(Note that the source tree in these archives is
mostly for packaging and testing of SCons; consult the
README file for
information about how to build packages and how to run SCons from the
source tree. It's no longer handled by executing
python setup.py directly
from this package.)
A set of HTML pages documenting the API of the latest SCons release. These are generated by sphinx from the SCons source code and docstrings.
The API docs are an internal resource, helpful for developing SCons. The distinction between "public API", which comes with consistency guarantees, and "internal API", which does not, is not necessarily clear from these docs; the public API is what appears in the manpage. There's also kind of an intermediate API: methods which might need to be tapped into by developers writing components to work with SCons, like new tools, builders, scanners, etc. The docstrings for internal classes and methods isn't really written consistently, or to a consistent style, and improvements here, even piecemeal, would be a nice addition to the project. If you want to help with this, drop a line to the mailing list, IRC channel, or Discord server - it's preferred to talk about it first before moving on to filing a bug report, or a Pull Request.
Our browsable GitHub repository
is a primary resource. The
branch contains the most-current development, but some long-term
development is carried out on subsidiary branches. Anyone may clone
the main repository from github. See the Branching and
Merging page in our wiki for a
description of the different branches and how we handle branch
management. There are also related SCons projects a level
up as well - look in https://github.com/SCons - each of these
is its own repository and has its own issue tracker, PRs, etc.
The SCons Buildbot, which runs the entire SCons test suite on multiple systems after every checkin. The SCons Buildbot is hosted by Bad Dog Consulting.