{"id":13441238,"url":"https://github.com/SCons/scons","last_synced_at":"2025-03-20T11:37:57.195Z","repository":{"id":37251358,"uuid":"104670160","full_name":"SCons/scons","owner":"SCons","description":"SCons - a software construction tool","archived":false,"fork":false,"pushed_at":"2024-05-22T17:41:14.000Z","size":24711,"stargazers_count":1967,"open_issues_count":654,"forks_count":310,"subscribers_count":63,"default_branch":"master","last_synced_at":"2024-05-22T21:34:03.805Z","etag":null,"topics":["build-automation","build-tool","build-tools","python-3-5","python-3-6","python3","python37","python38","scons"],"latest_commit_sha":null,"homepage":"http://scons.org","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/SCons.png","metadata":{"files":{"readme":"README-SF.rst","changelog":"CHANGES.txt","contributing":"CONTRIBUTING.rst","funding":".github/FUNDING.yml","license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"github":["bdbaddog","mwichmann"],"patreon":"bdbaddog"}},"created_at":"2017-09-24T19:23:46.000Z","updated_at":"2024-05-28T02:43:11.966Z","dependencies_parsed_at":"2023-02-15T20:00:25.246Z","dependency_job_id":"e910867c-19ec-4d37-82fc-a47795e060ce","html_url":"https://github.com/SCons/scons","commit_stats":{"total_commits":7267,"total_committers":150,"mean_commits":"48.446666666666665","dds":0.7209302325581395,"last_synced_commit":"58eb21173ffa02cdcb47aa78ad492b10e0def602"},"previous_names":[],"tags_count":51,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SCons%2Fscons","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SCons%2Fscons/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SCons%2Fscons/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/SCons%2Fscons/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/SCons","download_url":"https://codeload.github.com/SCons/scons/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":221759944,"owners_count":16876323,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["build-automation","build-tool","build-tools","python-3-5","python-3-6","python3","python37","python38","scons"],"created_at":"2024-07-31T03:01:31.479Z","updated_at":"2024-10-28T01:30:24.469Z","avatar_url":"https://github.com/SCons.png","language":"Python","readme":"SCons - a software construction tool\n####################################\n\nWelcome to the SCons development tree.  The real purpose of this tree is to\npackage SCons for production distribution in a variety of formats, not just to\nhack SCons code.\n\nIf all you want to do is install and run SCons, it will be easier for you to\ndownload and install the scons-{version}.tar.gz or scons-{version}.zip package\nrather than to work with the packaging logic in this tree.\n\nTo the extent that this tree is about building SCons packages, the *full*\ndevelopment cycle is not just to test the code directly, but to package SCons,\nunpack the package, \"install\" SCons in a test subdirectory, and then to run\nthe tests against the unpacked and installed software.  This helps eliminate\nproblems caused by, for example, failure to update the list of files to be\npackaged.\n\nFor just working on making an individual change to the SCons source, however,\nyou don't actually need to build or install SCons; you *can* actually edit and\nexecute SCons in-place.  See the following sections below for more\ninformation:\n\n    `Making Changes`_\n        How to edit and execute SCons in-place.\n\n    `Debugging`_\n        Tips for debugging problems in SCons.\n\n    `Testing`_\n        How to use the automated regression tests.\n\n    `Development Workflow`_\n        An example of how to put the edit/execute/test pieces\n        together in a reasonable development workflow.\n\n\nLatest Version\n==============\n\nBefore going further, you can check that the package you have is the latest\nversion at the SCons download page:\n\n        http://www.scons.org/pages/download.html\n\n\nExecution Requirements\n======================\n\nRunning SCons requires Python 3.6 or higher. There should be no other\ndependencies or requirements to run standard SCons.\nThe last release to support Python 3.5 was 4.2.0.\n\nThe default SCons configuration assumes use of the Microsoft Visual C++\ncompiler suite on Win32 systems, and assumes a C compiler named 'cc', a C++\ncompiler named 'c++', and a Fortran compiler named 'gfortran' (such as found\nin the GNU C compiler suite) on any other type of system.  You may, of course,\noverride these default values by appropriate configuration of Environment\nconstruction variables.\n\nBy default, SCons knows how to search for available programming tools on\nvarious systems--see the SCons man page for details.  You may, of course,\noverride the default SCons choices made by appropriate configuration of\nEnvironment construction variables.\n\n\nInstallation Requirements\n=========================\n\nNothing special.\n\n\nExecuting SCons Without Installing\n==================================\n\nYou can execute the local SCons directly from the SCons subdirectory by first\nsetting the SCONS_LIB_DIR environment variable to the local SCons\nsubdirectory, and then executing the local scripts/scons.py script to\npopulate the build/scons/ subdirectory.  You would do this as follows on a\nLinux or UNIX system (using sh or a derivative like bash or ksh)::\n\n        $ setenv MYSCONS=`pwd`\n        $ python $MYSCONS/scripts/scons.py [arguments]\n\nOr on Windows::\n\n        C:\\scons\u003eset MYSCONS=%cd%\n        C:\\scons\u003epython %MYSCONS%\\scripts\\scons.py [arguments]\n\nAn alternative approach is to skip the above and use::\n\n        $ python scripts/scons.py [arguments]\n\n\nYou can use the -C option to have SCons change directory to another location\nwhere you already have a build configuration set up::\n\n    $ python scripts/scons.py -C /some/other/location [arguments]\n\nFor simplicity in the following examples, we will only show the bootstrap.py\napproach.\n\n\nInstallation\n============\n\n    Note: You don't need to build SCons packages or install SCons if you just\n    want to work on developing a patch.  See the sections about `Making\n    Changes`_ and `Testing`_ below if you just want to submit a bug fix or\n    some new functionality.\n\nAssuming your system satisfies the installation requirements in the previous\nsection, install SCons from this package by first populating the build/scons/\nsubdirectory.  (For an easier way to install SCons, without having to populate\nthis directory, use the scons-{version}.tar.gz or scons-{version}.zip\npackage.)\n\n\nInstall the built SCons files\n-----------------------------\n\nAny of the above commands will populate the build/scons/ directory with the\nnecessary files and directory structure to use the Python-standard setup\nscript as follows on Linux or UNIX::\n\n        # python setup.py install\n\nOr on Windows::\n\n        C:\\scons\u003epython setup.py install\n\nBy default, the above commands will do the following:\n\n- Install scripts named \"scons\" and \"sconsign\" scripts in the default system\n  script directory (/usr/bin or C:\\\\Python\\*\\\\Scripts, for example).\n\n- Install \"scons-4.7.0.exe\" and \"scons.exe\" executables in the Python\n  prefix directory on Windows (C:\\\\Python\\*, for example).\n\n- Install the SCons build engine (a Python module) in the standard Python library directory\n  (/usr/lib/python\\*/site-packages or C:\\\\Python*\\\\Lib\\\\site-packages).\n\nMaking Changes\n==============\n\nBecause SCons is implemented in a scripting language, you don't need to build\nit in order to make changes and test them.\n\nVirtually all of the SCons functionality exists in the \"build engine,\" the\nSCons subdirectory hierarchy that contains all of the modules that\nmake up SCons.  The scripts/scons.py wrapper script exists mainly to find\nthe appropriate build engine library and then execute it.\n\nIn order to make your own changes locally and test them by hand, simply edit\nmodules in the local SCons subdirectory tree and then running\n(see the section above about `Executing SCons Without Installing`_)::\n\n    $ python scripts/scons.py [arguments]\n\nIf you want to be able to just execute your modified version of SCons from the\ncommand line, you can make it executable and add its directory to your $PATH\nlike so::\n\n    $ chmod 755 scripts/scons.py\n    $ export PATH=$PATH:`pwd`/scripts\n\nYou should then be able to run this version of SCons by just typing \"scons.py\"\nat your UNIX or Linux command line.\n\nNote that the regular SCons development process makes heavy use of automated\ntesting.  See the `Testing`_ and `Development Workflow`_ sections below for more\ninformation about the automated regression tests and how they can be used in a\ndevelopment cycle to validate that your changes don't break existing\nfunctionality.\n\n\nDebugging\n=========\n\nPython comes with a good interactive debugger.  When debugging changes by hand\n(i.e., when not using the automated tests), you can invoke SCons under control\nof the Python debugger by specifying the --debug=pdb option::\n\n    $ scons --debug=pdb [arguments]\n    \u003e /home/knight/scons/SCons/Script/Main.py(927)_main()\n    -\u003e default_warnings = [ SCons.Warnings.CorruptSConsignWarning,\n    (Pdb)\n\nOnce in the debugger, you can set breakpoints at lines in files in the build\nengine modules by providing the path name of the file relative to the\ntop directory (that is, including the SCons/ as the first directory\ncomponent)::\n\n    (Pdb) b SCons/Tool/msvc.py:158\n\nThe debugger also supports single stepping, stepping into functions, printing\nvariables, etc.\n\nTrying to debug problems found by running the automated tests (see the\n`Testing`_ section, below) is more difficult, because the test automation\nharness re-invokes SCons and captures output. Consequently, there isn't an\neasy way to invoke the Python debugger in a useful way on any particular SCons\ncall within a test script.\n\nThe most effective technique for debugging problems that occur during an\nautomated test is to use the good old tried-and-true technique of adding\nstatements to print tracing information.  But note that you can't just use\nthe \"print\" function, or even \"sys.stdout.write()\" because those change the\nSCons output, and the automated tests usually look for matches of specific\noutput strings to decide if a given SCons invocation passes the test -\nso these additions may cause apparent failures different than the one you\nare trying to debug.\n\nTo deal with this, SCons supports a Trace() function that (by default) will\nprint messages to your console screen (\"/dev/tty\" on UNIX or Linux, \"con\" on\nWindows).  By adding Trace() calls to the SCons source code::\n\n    def sample_method(self, value):\n        from SCons.Debug import Trace\n        Trace('called sample_method(%s, %s)\\n' % (self, value))\n\nYou can then run automated tests that print any arbitrary information you wish\nabout what's going on inside SCons, without interfering with the test\nautomation.\n\nThe Trace() function can also redirect its output to a file, rather than the\nscreen::\n\n    def sample_method(self, value):\n        from SCons.Debug import Trace\n        Trace('called sample_method(%s, %s)\\n' % (self, value),\n              file='trace.out')\n\nWhere the Trace() function sends its output is stateful: once you use the\n\"file=\" argument, all subsequent calls to Trace() send their output to the\nsame file, until another call with a \"file=\" argument is reached.\n\n\nTesting\n=======\n\nTests are run by the runtest.py script in this directory.\n\nThere are two types of tests in this package:\n\n1. Unit tests for individual SCons modules live underneath the SCons\n   subdirectory and have the same base name as the module with \"Tests.py\"\n   appended--for example, the unit test for the Builder.py module is the\n   BuilderTests.py script.\n\n2. End-to-end tests of SCons live in the test/ subdirectory.\n\nYou may specifically list one or more tests to be run::\n\n        $ python runtest.py SCons/BuilderTests.py\n\n        $ python runtest.py test/option-j.py test/Program.py\n\nYou also use the -f option to execute just the tests listed in a specified\ntext file::\n\n        $ cat testlist.txt\n        test/option-j.py\n        test/Program.py\n        $ python runtest.py -f testlist.txt\n\nOne test must be listed per line, and any lines that begin with '#' will be\nignored (allowing you, for example, to comment out tests that are currently\npassing and then uncomment all of the tests in the file for a final validation\nrun).\n\nThe runtest.py script also takes a -a option that searches the tree for all of\nthe tests and runs them::\n\n        $ python runtest.py -a\n\nIf more than one test is run, the runtest.py script prints a summary of how\nmany tests passed, failed, or yielded no result, and lists any unsuccessful\ntests.\n\nThe above invocations all test directly the files underneath the SCons/\nsubdirectory, and do not require that a build be performed first.\n\nDevelopment Workflow\n====================\n\n    Caveat: The point of this section isn't to describe one dogmatic workflow.\n    Just running the test suite can be time-consuming, and getting a patch to\n    pass all of the tests can be more so.  If you're genuinely blocked, it may\n    make more sense to submit a patch with a note about which tests still\n    fail, and how.  Someone else may be able to take your \"initial draft\" and\n    figure out how to improve it to fix the rest of the tests.  So there's\n    plenty of room for use of good judgement.\n\nThe various techniques described in the above sections can be combined to\ncreate simple and effective workflows that allow you to validate that patches\nyou submit to SCons don't break existing functionality and have adequate\ntesting, thereby increasing the speed with which they can be integrated.\n\nFor example, suppose your project's SCons configuration is blocked by an SCons\nbug, and you decide you want to fix it and submit the patch.  Here's one\npossible way to go about doing that (using UNIX/Linux as the development\nplatform, Windows users can translate as appropriate)):\n\n- Change to the top of your checked-out SCons tree.\n\n- Confirm that the bug still exists in this version of SCons by using the -C\n   option to run the broken build::\n\n      $ python scripts/scons.py -C /home/me/broken_project .\n\n- Fix the bug in SCons by editing appropriate module files underneath\n  SCons.\n\n- Confirm that you've fixed the bug affecting your project::\n\n      $ python scripts/scons.py -C /home/me/broken_project .\n\n- Test to see if your fix had any unintended side effects that break existing\n  functionality::\n\n      $ python runtest.py -a -o test.log\n\n  Be patient, there are more than 1100 test scripts in the whole suite.  If you\n  are on UNIX/Linux, you can use::\n\n      $ python runtest.py -a | tee test.log\n\n  instead so you can monitor progress from your terminal.\n\n  If any test scripts fail, they will be listed in a summary at the end of the\n  log file.  Some test scripts may also report NO RESULT because (for example)\n  your local system is the wrong type or doesn't have some installed utilities\n  necessary to run the script.  In general, you can ignore the NO RESULT list,\n  beyond having checked once that the tests that matter to your change are\n  actually being executed on your test system!\n\n- Cut-and-paste the list of failed tests into a file::\n\n      $ cat \u003e failed.txt\n      test/failed-test-1.py\n      test/failed-test-2.py\n      test/failed-test-3.py\n      ^D\n      $\n\n- Now debug the test failures and fix them, either by changing SCons, or by\n  making necessary changes to the tests (if, for example, you have a strong\n  reason to change functionality, or if you find that the bug really is in the\n  test script itself).  After each change, use the runtest.py -f option to\n  examine the effects of the change on the subset of tests that originally\n  failed::\n\n      $ [edit]\n      $ python runtest.py -f failed.txt\n\n  Repeat this until all of the tests that originally failed now pass.\n\n- Now you need to go back and validate that any changes you made while getting\n  the tests to pass didn't break the fix you originally put in, and didn't\n  introduce any *additional* unintended side effects that broke other tests::\n\n      $ python scripts/scons.py -C /home/me/broken_project .\n      $ python runtest.py -a -o test.log\n\n  If you find any newly-broken tests, add them to your \"failed.txt\" file and\n  go back to the previous step.\n\nOf course, the above is only one suggested workflow.  In practice, there is a\nlot of room for judgment and experience to make things go quicker.  For\nexample, if you're making a change to just the Java support, you might start\nlooking for regressions by just running the test/Java/\\*.py tests instead of\nrunning all of \"runtest.py -a\".\n\n\nBuilding Packages\n=================\n\nWe use SCons to build its own packages.  If you\nalready have an appropriate version of SCons installed on your system, you can\nbuild everything by simply running it::\n\n        $ scons\n\nIf you don't have SCons already installed on your\nsystem, you can use the supplied bootstrap.py script (see the section above\nabout `Executing SCons Without Installing`_)::\n\n        $ python scripts/scons.py build/scons\n\nDepending on the utilities installed on your system, any or all of the\nfollowing packages will be built::\n\n    SCons-4.7.0-py3-none-any.whl\n    SCons-4.7.0ayyyymmdd.tar.gz\n    SCons-4.7.0ayyyymmdd.zip\n    scons-doc-4.7.0ayyyymmdd.tar.gz\n    scons-local-4.7.0ayyyymmdd.tar.gz\n    scons-local-4.7.0ayyyymmdd.zip\n    scons-local-4.7.0ayyyymmdd.pyz\n\nThe SConstruct file is supposed to be smart enough to avoid trying to build\npackages for which you don't have the proper utilities installed.\n\nIf you receive a build error, please report it to the scons-users mailing list\nand open a bug report on the SCons issue tracker on GitHub.\n\nNote that in addition to creating the above packages, the default build will\nalso unpack one or more of the packages for testing.\n\n\nContents of this Package\n========================\n\nNot guaranteed to be up-to-date (but better than nothing):\n\nbench/\n    A subdirectory for benchmarking scripts, used to perform timing tests\n    to decide what specific idioms are most efficient for various parts of\n    the code base.  We check these in so they're available in case we have\n    to revisit any of these decisions in the future.\n\nbin/\n    Miscellaneous utilities used in SCons development.  Right now,\n    some of the stuff here includes:\n\n    - a script that runs pychecker on our source tree;\n\n    - a script that counts source and test files and numbers of lines in each;\n\n    - a prototype script for capturing sample SCons output in xml files;\n\n    - a script that can profile and time a packaging build of SCons itself;\n\n    - a copy of xml_export, which can retrieve project data from SourceForge;\n      and\n\n    - scripts and a Python module for translating the SCons home-brew XML\n      documentation tags into DocBook and man page format\n\n\nbootstrap.py\n    Obsolete packaging logic.\n\n\ndebian/\n    Files needed to construct a Debian package. The contents of this directory\n    are dictated by the Debian Policy Manual\n    (http://www.debian.org/doc/debian-policy). The package will not be\n    accepted into the Debian distribution unless the contents of this\n    directory satisfy the relevant Debian policies.\n\ndoc/\n    SCons documentation.  A variety of things here, in various stages of\n    (in)completeness.\n\nLICENSE\n    A copy of the copyright and terms under which SCons is distributed (the\n    Open Source Initiative-approved MIT license).\n\nLICENSE-local\n    A copy of the copyright and terms under which SCons is distributed for\n    inclusion in the scons-local-{version} packages.  This is the same as\n    LICENSE with a preamble that specifies the licensing terms are for SCons\n    itself, not any other package that includes SCons.\n\nREADME.rst\n    What you're looking at right now.\n\nREADME-local\n    A README file for inclusion in the scons-local-{version} packages.\n    Similar to this file, but stripped down and modified for people looking at\n    including SCons in their shipped software.\n\nruntest.py\n    Script for running SCons tests.  By default, this will run a test against\n    the code in the local SCons tree, so you don't have to do a build before\n    testing your changes.\n\nSConstruct\n    The file describing to SCons how to build the SCons distribution.\n\n    (It has been pointed out that it's hard to find the SCons API in this\n    SConstruct file, and that it looks a lot more like a pure Python script\n    than a build configuration file.  That's mainly because all of the magick\n    we have to perform to deal with all of the different packaging formats\n    requires a lot of pure Python manipulation.  In other words, don't look at\n    this file for an example of how easy it is to use SCons to build \"normal\"\n    software.)\n\nSCons/\n    Where the actual source code is kept, of course.\n\ntest/\n    End-to-end tests of the SCons utility itself.  These are separate from the\n    individual module unit tests, which live side-by-side with the modules\n    under SCons.\n\ntesting/\n    SCons testing framework.\n\nDocumentation\n=============\n\nSee the RELEASE.txt file for notes about this specific release, including\nknown problems.  See the CHANGES.txt file for a list of changes since the\nprevious release.\n\nThe doc/man/scons.1 man page is included in this package, and contains a\nsection of small examples for getting started using SCons.\n\nAdditional documentation for SCons is available at:\n\n        http://www.scons.org/documentation.html\n\n\nLicensing\n=========\n\nSCons is distributed under the MIT license, a full copy of which is available\nin the LICENSE file.\n\n\nReporting Bugs\n==============\n\nThe SCons project welcomes bug reports and feature requests.\n\nPlease make sure you send email with the problem or feature request to\nthe SCons users mailing list, which you can join via the link below:\n\n        http://two.pairlist.net/mailman/listinfo/scons-users\n\nOnce you have discussed your issue on the users mailing list and the\ncommunity has confirmed that it is either a new bug or a duplicate of an\nexisting bug, then please follow the instructions the community provides\nto file a new bug or to add yourself to the CC list for an existing bug\n\nYou can explore the list of existing bugs, which may include workarounds\nfor the problem you've run into on GitHub Issues:\n\n        https://github.com/SCons/scons/issues\n\n\nMailing Lists\n=============\n\nIn addition to the scons-users list which is appropriate for almost any\nquestion, there is a mailing list specifically for developers of SCons\nYou may send questions or comments to the list at:\n\n        scons-dev@scons.org\n\nYou may subscribe to the developer's mailing list using form on this page:\n\n        http://two.pairlist.net/mailman/listinfo/scons-dev\n\nSubscription to the developer's mailing list is by approval.  In practice, no\none is refused list membership, but we reserve the right to limit membership\nin the future and/or weed out lurkers.\n\nNote that while this list still exists, the number of different places you\ncan talk about SCons means it is no longer very active.  GitHub has\nsupport for discussions as well as for issues, and there is usually more\nimmediacy on the Discord chat, so these are probably now considered the\npreferred places for \"development\" topics.\n\n\nDonations\n=========\n\nIf you find SCons helpful, please consider making a donation (of cash,\nsoftware, or hardware) to support continued work on the project.  Information\nis available at:\n\n        http://www.scons.org/donate.html\n\nor\n\nGitHub Sponsors button on https://github.com/scons/scons\n\n\nFor More Information\n====================\n\nCheck the SCons web site at:\n\n        http://www.scons.org/\n\n\nAuthor Info\n===========\n\nSCons was originally written by Steven Knight, knight at baldmt dot com.\nSince around 2010 it has been maintained by the SCons\ndevelopment team, co-managed by Bill Deegan and Gary Oberbrunner, with\nmany contributors, including but not at all limited to:\n\n- Chad Austin\n- Dirk Baechle\n- Charles Crain\n- William Deegan\n- Steve Leblanc\n- Rob Managan\n- Greg Noel\n- Gary Oberbrunner\n- Anthony Roach\n- Greg Spencer\n- Tom Tanner\n- Anatoly Techtonik\n- Christoph Wiedemann\n- Russel Winder\n- Mats Wichmann\n\n\\... and many others.\n\nCopyright (c) 2001 - 2024 The SCons Foundation\n\n","funding_links":["https://github.com/sponsors/bdbaddog","https://github.com/sponsors/mwichmann","https://patreon.com/bdbaddog"],"categories":["HarmonyOS","\u003ca id=\"tag-dev\" href=\"#tag-dev\"\u003eDev\u003c/a\u003e","Build Tools","Python","Desktop App Development","构建工具","Other","\u003ca name=\"programming\"\u003e\u003c/a\u003eProgramming"],"sub_categories":["Windows Manager","\u003ca id=\"tag-dev.build\" href=\"#tag-dev.build\"\u003eBuild\u003c/a\u003e","JWT","Data Management"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FSCons%2Fscons","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FSCons%2Fscons","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FSCons%2Fscons/lists"}