Developers Wanted:
SCons welcomes contributors. You can contribute to the code of SCons itself, the documentation, the examples/ cookbook, by commention in public forums and on GitHub, and more. If you're interested, we'd love to hear from you at scons-users or on the Discord channel
What it takes to contribute to SCons:
The Developer's Guidelines go into reasonable detail about how the project evolves while remaining 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.
- SCons uses GitHub to manage receiving patches via Pull Requests from the community.
Guidelines:
Please take a look at the current guidelines before deciding to hop on board.
GitHub:
The code repository for SCons is hosted on GitHub.
The master
branch contains current development.
There is a branch and tag made at each release, but currently all development, including bugfixes, goes to `master. Occasionally some long-term development is carried out on a branch.
Anyone may clone the main repository from GitHub.
Latest API documentation
A set of HTML pages documenting the internal APIs 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 aren't really written consistently, or to a consistent style, and improvements here, even piecemeal, would be a nice addition to the project.
How to reach the community
The project team prefers that topics get discussed in public first, to reduce the "project management" burden on GitHub of working with entries that aren't likely to go anywhere, or are duplicates, so please reach out to the community via mailing list, or Discord server before starting one of these:
- Filing an issue or enhancement request
- Starting a topic discussion
- Submitting a Pull Request.