Mailman 3 - Scons-users

Fwd: adding text to compile line
by Jeremy Elson Feb. 9, 2026

Feb. 9, 2026

Hi, sorry for resurrecting this old thread! 2 years ago I mentioned on this list (quoted below) that I'd made a little 'Spinner' utility for scons, which generates more compact build output. Bill asked if I could contribute it back to the scons-contrib repo, which after a mere 2 year delay I have finally done: https://github.com/SCons/scons-contrib/pull/54 Best, Jeremy On Mon, Jan 22, 2024 at 11:38 PM Jeremy Elson <jelson(a)gmail.com> wrote: > Sure! > > > On Sun, Jan 21, 2024 at 6:29 PM Bill Deegan <bill(a)baddogconsulting.com> > wrote: > >> Jeremy, >> >> Any chance you could contribute that to the >> https://github.com/SCons/scons-contrib repo? >> >> Pretty interesting. >> -Bill >> >> On Sun, Jan 21, 2024 at 1:40 PM Jeremy Elson <jelson(a)gmail.com> wrote: >> >>> This is a lot more than what OP asked for, but I'll describe the custom >>> output code I wrote for one of my Scons-based build systems.(It's not >>> open-source, so I can't link to the full code.) >>> >>> My goal was to replace all the raw command-line output with something >>> like: >>> >>> Compiling src/app/foo.c >>> Compiling src/app/bar.c >>> Linking build/libs/libfoo.a >>> Linking build/output/foo.elf >>> Signing build/output/foo.elf >>> >>> In this case, "Compiling" and "Linking" are standard scons rules; >>> "Signing" is a custom builder. The trick is that for some of the outputs, >>> such as Compiling, should show the name of the source. Others, such as >>> Linking, show the name of the target. >>> >>> First, I defined a class called SpinnerPrinter that looks sort of like >>> this: >>> >>> class SpinnerPrinter: >>> SPINNER = '<<spinner>>' >>> SOURCE = 'src' >>> TARGET = 'trg' >>> >>> def spin_source(s): >>> return SpinnerPrinter.SPINNER + SpinnerPrinter.SOURCE + s >>> >>> def spin_target(s): >>> return SpinnerPrinter.SPINNER + SpinnerPrinter.TARGET + s >>> >>> Then, in my function that sets up the scons build env, I have code that >>> looks like the examples below. I call spin_source to indicate the build >>> output should use the source filenames, and spin_target to show it should >>> be target. The COMSTRs all end up being configuration strings for the >>> custom output function. >>> >>> if not build_options.verbose: >>> env['PRINT_CMD_LINE_FUNC'] = SpinnerPrinter().spinner_print >>> # Overrides to standard builders >>> env['CCCOMSTR'] = SpinnerPrinter.spin_source("Compiling") >>> env['ASPPCOMSTR'] = SpinnerPrinter.spin_source("Assembling") >>> env['LINKCOMSTR'] = SpinnerPrinter.spin_target("Linking") >>> env['ARCOMSTR'] = SpinnerPrinter.spin_target("Creating library") >>> >>> # locally defined builders >>> env['PROTOBUFCOMSTR'] = SpinnerPrinter.spin_source("Creating protobuf") >>> env['SIGNCOMSTR'] = SpinnerPrinter.spin_source("Signing") >>> >>> The SpinnerPrinter class has a function spinner_print that uses the >>> config string to generate the output based on the config >>> string generated by spin_source and spin_target: >>> >>> def spinner_print(self, s, target, source, env): >>> # Regular (non-spinner-aware) strings just get emitted as >>> # usual >>> if not s.startswith(self.SPINNER): >>> sys.stdout.write(s + "\n") >>> return >>> >>> # take off the marker >>> s = s[len(self.SPINNER):] >>> >>> # figure out if we are supposed to print the source or target >>> which = s[0:3] >>> >>> # Generate the prefix (the part printed before the filename). >>> print_prefix = s[3:] >>> # Find out what filename to print as part of the output. We'd >>> # rather print the name of the source, but steps such as >>> # library creation have a zillion sources and one target, so >>> # we'll print the target instead for those. >>> if which == SpinnerPrinter.SOURCE: >>> file_to_print = source[0] >>> else: >>> file_to_print = target[0] >>> fn_to_print = os.path.realpath(str(file_to_print)) >>> >>> # Combine the directive we were given (e.g. "Compiling") >>> # with the filename >>> sys.stdout.write(f"{print_prefix} {fn_to_print}\n" >>> >>> This can be made much fancier; I've elided various details. For example, >>> the real spinner senses if stdout is a tty. If it is a tty, it uses ANSI >>> escape sequences so the output lines overwrite themselves, and it prints >>> only the part of the filename that fits on a single terminal line (after >>> sensing its width). So when our team builds from the command-line, a normal >>> build does not use any terminal space at all! When running from a script, >>> the "Compiling" and "Linking" lines all appear as separate lines. And >>> without the --verbose option, the entire custom output block is skipped and >>> full command-lines get printed (the default scons behavior). >>> >>> Hopefully this helps someone! We've been very happy with how it works >>> (and with scons in general). >>> >>> -Jeremy >>> >>> On Sun, Jan 21, 2024 at 1:07 PM Bill Deegan <bill(a)baddogconsulting.com> >>> wrote: >>> >>>> Dagg, >>>> >>>> What Mats said.. with more detail. >>>> >>>> So if your compiling c++, the relevant variables are >>>> CXXCOM, CXXCOMSTR >>>> SHCXXCOM, SHCXXCOMSTR >>>> >>>> The *STR variables are what is output to the screen, the non *STR are >>>> what's used to build the command line and execute. >>>> replace CXX with CC for C compiles.. >>>> You can see the complete list of such variables in the manpage: >>>> https://scons.org/doc/production/HTML/scons-man.html >>>> >>>> Hope this helps~! >>>> -=Bill >>>> >>>> On Sun, Jan 21, 2024 at 11:07 AM Mats Wichmann <mats(a)wichmann.us> >>>> wrote: >>>> >>>>> On January 21, 2024 5:40:14 AM MST, daggs via Scons-users < >>>>> scons-users(a)scons.org> wrote: >>>>> >Greetings, >>>>> > >>>>> >I want to add a prefix the compile line scons is displaying, is it >>>>> possible? >>>>> > >>>>> >Thanks, >>>>> > >>>>> >Dagg >>>>> >_______________________________________________ >>>>> >Scons-users mailing list >>>>> >Scons-users(a)scons.org >>>>> >https://pairlist4.pair.net/mailman/listinfo/scons-users >>>>> >>>>> yes. >>>>> >>>>> sorry not at a place I can answer more fully, but can modify the >>>>> relevant COMSTR (command string), or supply your own $PRINT_CMD_LINE_FUNC >>>>> -- >>>>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>>>> _______________________________________________ >>>>> Scons-users mailing list >>>>> Scons-users(a)scons.org >>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users >>>>> >>>> _______________________________________________ >>>> Scons-users mailing list >>>> Scons-users(a)scons.org >>>> https://pairlist4.pair.net/mailman/listinfo/scons-users >>>> >>> _______________________________________________ >>> Scons-users mailing list >>> Scons-users(a)scons.org >>> https://pairlist4.pair.net/mailman/listinfo/scons-users >>> >> _______________________________________________ >> Scons-users mailing list >> Scons-users(a)scons.org >> https://pairlist4.pair.net/mailman/listinfo/scons-users >> >

2 2

New SCons User and Dev mailing list hosts
by Bill Deegan Dec. 6, 2025

Dec. 6, 2025

Greetings, Our mailing list provider for many years, Pair.com will shortly be discontinuing this service. Thankfully the Python Software Foundation has agreed to host the mailing lists going forward. We'll be updating the mailing list information on https://scons.org shortly to point to the new mailing lists, and we've migrated all the users and the mailing list archive to PSF. Note that this does entail a domain name change for the lists. (From scons.org -> python.org) You will start getting email from scons-users(a)python.org and/or scons-dev(a)python.org, and should use those addresses for sending. You can manage your subscriptions at the following URLS: https://mail.python.org/mailman3/lists/scons-users.python.org/ or https://mail.python.org/mailman3/lists/scons-dev.python.org/ -Bill SCons project manager.

1 0

Test email from new server
by Bill Deegan Dec. 6, 2025

Dec. 6, 2025

Testing -Bill SCons Project Manager

1 0

SCons 4.10.0 released
by Bill Deegan Oct. 2, 2025

Oct. 2, 2025

A new SCons release, 4.9.10, is now available on the SCons download page: https://scons.org/pages/download.html Here is a summary of the changes since 4.9.1: CHANGED/ENHANCED EXISTING FUNCTIONALITY --------------------------------------- - Nodes are now treated as PathLike objects. - Replace use of old conditional expression idioms with the official one from PEP 308 introduced in Python 2.5 (2006). The idiom being replaced (using and/or) is regarded as error prone. - MSVC: The following shell environment variables are now included in the environment used by SCons to initialize MSVC when defined: VCPKG_DISABLE_METRICS, VCPKG_ROOT, POWERSHELL_TELEMETRY_OPTOUT, PSDisableModuleAnalysisCacheCleanup, and PSModuleAnalysisCachePath. A subset of the shell environment PSModulePath is included in the environment used by SCons to initialize MSVC when defined. None of these variables and values are propagated to the user's SCons environment after running the MSVC batch files. - TEMPFILE: A UserError exception is raised when encoding the contents of the tempfile fails due to a limited set of expected exceptions (e.g., UnicodeError). FIXES ----- - Fixed SCons.Variables.PackageVariable to correctly test the default setting against both enable & disable strings. (Fixes #4702) - MSVC: Fixed a significant delay experienced in the Github Actions windows 2022 and 2025 runners due to the environment used by SCons to initialize MSVC when the Visual Studio vcpkg component is installed. The Github Actions windows 2019 runner was not affected. - Fix the variant dir component being missing from generated source file paths with CompilationDatabase() builder (Fixes #4003). - Ninja tool generate_command() fixed to call subst() with correct arguments in ListAction case. Unit tests added for generate_command. - Fix the SCons.Scanner.LaTeX to mimic LaTeX's search method. - Ninja tool now quotes targets (if necessary) when calling back to SCons - both in the POST request constructed to contact the daemon, and in the command eventually issued from the deamon. - Ninja tool is adjusted to recognize and emit the right rule in the case of special actions that the tool recognizes, like Copy. This was working in the case of single commands, but not when part of a list of actions. Recognition only happens if the special action is first in the list. - Fix a test problem on Windows where UNC tests failed due to incorrect path munging if a non-default %TEMP% was defined (as in moving to a Dev Drive). - Fix Issue #4746. The TEMPFILE is written in utf-8 encoding by default. If the tempfile contents cannot be decoded by the command the tempfile is passed to, (new) TEMPPFILEENCODING can be used to speficy a different encoding to use. On Windows, the username may be a cause of this, as the default path for temporary files includes the username. Setting (existing) TEMPFILEDIR may also help in this case. - Tweak runtest.py and test framework to more reliably get the requested Python binary (for odd Windows setups + Python launcher) - Fix the tempfile encoding test regex strings to remove warnings in python 3.12 and 3.13. - Incremental builds in Interactive mode could fail on platforms that support batch mode (currently: Windows). Change the way the changed and unchanged target and source lists are accounted for to resolve. Fixes #3029. IMPROVEMENTS ------------ - Virtualenv support module modernized: previously looked first for an unofficial approach from before venv support was made part of Python in 3.3; now looks for the official approach first. This in an internal detail, the API is unchanged. - Add internal routines to manipulate publicly visible argument and target lists. These interfaces are not part of the public API. - Improve the error message when an environment method is called which does not exist in that environment. Mostly this is intended to be a bit more helpful in the case of a builder which did not instantiate. PACKAGING --------- - The generated roff (.1) manpages are now included in the scons-doc tarball built at part of the release process, in addition to the html and txt versions. For distribution packaging, the manpages can be extracted from here (downloadable from https://scons.org/doc/ using a a version-specific URL, e.g. https://scons.org/doc/4.9.1/scons-doc-4.9.1.tar.gz). DOCUMENTATION ------------- - Clarify how pre/post actions on an alias work. - Improve the description of PackageVariable. - The "API Docs" build (Sphinx) configuration is improved, and SConsDoc and SConsExample are now included - their API is interesting to developers working on SCons (needed to write docs), even if not part of "The SCons API" itself. - Missing documentation for the Virtualenv() function is added. Note that the User Guide previously described a negative outcome as returning None. It is now explicit that the path is returned if running in a virtualenv, and an empty (falsy) string if not. - Improve the wording of Configure methods. - Improve the wording of AppendENVPath and PrependENVPath in manpage. - Improve documentation of builder methods and builder objects. - All the User Guide sections now have textual anchors, meaning there no longer be build-generated numeric tags like https://scons.org/doc/production/HTML/scons-user.html#id1514 DEVELOPMENT ----------- - runtest.py once again finds "external" tests, such as the tests for tools in scons-contrib. An earlier rework had broken this. Fixes #4699. - Clean up C and C++ FLAGS tests. Tests which use a real compiler are now more clearly distinguished (-live.py suffix and docstring). - Fix a couple of unit tests to not fail with Python 3.14. These involve expectations for bytecode strings and error message contents; there was no problem with SCons itself using 3.14. - Move the GitHub workflow test runner files from the SCons root to the ci subdirectory of the testing directory. - GitHub: Enable the interactive tests on windows. - GitHub: Enable the packaging tar xz test on windows. - GitHub: Exclude two ninja tests that consistently fail on MacOS in the experimental tests workflow. - GitHub: Add a workflow file to test MSVC with optional environment variables. - GitHub: Populate the MSVC cache before running the test suite for select windows workflow files. - GitHub: Upload the failed_tests.log artifact on failure in select workflow files. - GitHub: Change the runtest workflow to allow the python version to be specified with the OS version. - Testing: Increase the default timeout from 20 seconds to 60 seconds in the testing framework wait_for method. The timeout was increased during isolated experiments of the interactive tests on windows. - Testing: Update the packaging tar bz2 and xz tests on on Windows. The packaging tar bz2 and xz tests should be skipped on Windows 10 and GitHub windows-2022. The packaging tar bz2 and xz tests should be run on Windows 11 and GitHub windows-2025. - Ninja: Increase the number of generated source files in the iterative speedup test from 200 to 250. Increasing the workload should reduce the likelihood that the ninja tests are slower. - Add more unit tests to internal AppendPath, PrependPath functions. Thanks to the following contributors listed below for their contributions to this release. ========================================================================================== .. code-block:: text git shortlog --no-merges -ns 4.9.1..HEAD 61 Mats Wichmann 46 Joseph Brill 25 William Deegan 6 Keith F. Prussing 1 Bill Prendergast 1 Edward Peek 1 Thaddeus Crews

1 0

SCons misses a dependency which results in incorrect output.
by Tal Dayan July 17, 2025

July 17, 2025

Hi all, We encountered this problem with the nextpnr tool and created here a small and independent example that demonstrates it. In the example below, a shell script 'command.sh' reads the source file 'file1' and writes it to the target file 'file2'. However, if the source file starts with 'bad' it exits with an error code, *after* creating the target file. The script `run.sh', runs scons three times with these values of the source file file1 'good', 'bad', and 'good'. The expectation is that after the third scons run, file2 should contain the value 'good' but it contains the value 'bad'. Do we miss anything or is it simply a bug? SConstruct: ---------------------------------------------- # SCons environment env = Environment() # Copy file1 → file2 using command.sh # Inject an error if file1 starts with 'bad" file2 = env.Command( target='file2', source='file1', action='./command.sh $SOURCE > $TARGET' ) # Make 'file2' the default target Default(file2) ---------------------------------------------- command.sh: ---------------------------------------------- #!/bin/bash # Usage: ./command input > output # Read from the first argument and copy to stdout cat "$1" # If the input file starts with 'bad', inject an error AFTER creating the output file. first_line=$(head -n 1 "$1") if [[ "$first_line" == bad* ]]; then exit 1 fi exit 0 ---------------------------------------------- run.sh ---------------------------------------------- #!/bin/bash # Clean up. rm -f .sconsign.dblite rm -f file[12] echo echo "---- Iteration 1: file1 = 'good'" echo "good" > file1 scons echo echo "File1" cat -n file1 echo "File2" cat -n file2 echo echo "---- Iteration 2: file1 = 'bad'" echo "bad" > file1 cat -n file1 scons echo echo "File1" cat -n file1 echo "File2" cat -n file2 echo echo "---- Iteration 3: file1 = 'good'" echo "good" > file1 cat -n file1 scons echo echo "File1" cat -n file1 echo "File2" cat -n file2 ---------------------------------------------- Run log: ---------------------------------------------- $ ./run.sh ---- Iteration 1: file1 = 'good' scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... ./command.sh file1 > file2 scons: done building targets. File1 1 good File2 1 good ---- Iteration 2: file1 = 'bad' 1 bad scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... ./command.sh file1 > file2 scons: *** [file2] Error 1 scons: building terminated because of errors. File1 1 bad File2 1 bad ---- Iteration 1: file1 = 'good' 1 good scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... scons: `file2' is up to date. scons: done building targets. File1 1 good File2 1 bad ----------------------------------------------

3 13

Re: [Scons-users] SCons misses a dependency which results in incorrect output.
by Tal Dayan July 16, 2025

July 16, 2025

A more readable version of the example files and log is available at https://github.com/FPGAwars/apio/issues/676 On Wed, Jul 16, 2025 at 9:35 AM Tal Dayan <tal(a)zapta.com> wrote: > Hi all, > > We encountered this problem with the nextpnr tool and created here a small > and independent example that demonstrates it. > > In the example below, a shell script 'command.sh' reads the source file > 'file1' and writes it to the target file 'file2'. However, if the > source file starts with 'bad' it exits with an error code, *after* > creating the target file. > > The script `run.sh', runs scons three times with these values of the > source file file1 'good', 'bad', and 'good'. The expectation is that after > the third scons run, file2 should contain the value 'good' but it contains > the value 'bad'. > > Do we miss anything or is it simply a bug? > > SConstruct: > > ---------------------------------------------- > # SCons environment > > env = Environment() > > > # Copy file1 → file2 using command.sh > > # Inject an error if file1 starts with 'bad" > > file2 = env.Command( > > target='file2', > > source='file1', > > action='./command.sh $SOURCE > $TARGET' > > ) > > > # Make 'file2' the default target > > Default(file2) > > ---------------------------------------------- > > > command.sh: > > ---------------------------------------------- > > #!/bin/bash > > # Usage: ./command input > output > > > # Read from the first argument and copy to stdout > > cat "$1" > > > # If the input file starts with 'bad', inject an error AFTER creating the > output file. > > > first_line=$(head -n 1 "$1") > > > if [[ "$first_line" == bad* ]]; then > > exit 1 > > fi > > > exit 0 > > ---------------------------------------------- > > > > run.sh > > ---------------------------------------------- > > #!/bin/bash > > > # Clean up. > > rm -f .sconsign.dblite > > rm -f file[12] > > > echo > > echo "---- Iteration 1: file1 = 'good'" > > echo "good" > file1 > > scons > > echo > > > echo "File1" > > cat -n file1 > > > echo "File2" > > cat -n file2 > > > > echo > > echo "---- Iteration 2: file1 = 'bad'" > > echo "bad" > file1 > > cat -n file1 > > scons > > echo > > > echo "File1" > > cat -n file1 > > > echo "File2" > > cat -n file2 > > > echo > > echo "---- Iteration 3: file1 = 'good'" > > echo "good" > file1 > > cat -n file1 > > scons > > echo > > > echo "File1" > > cat -n file1 > > > echo "File2" > > cat -n file2 > > ---------------------------------------------- > > > > Run log: > > ---------------------------------------------- > > $ ./run.sh > > > ---- Iteration 1: file1 = 'good' > > scons: Reading SConscript files ... > > scons: done reading SConscript files. > > scons: Building targets ... > > ./command.sh file1 > file2 > > scons: done building targets. > > > File1 > > 1 good > > File2 > > 1 good > > > ---- Iteration 2: file1 = 'bad' > > 1 bad > > scons: Reading SConscript files ... > > scons: done reading SConscript files. > > scons: Building targets ... > > ./command.sh file1 > file2 > > scons: *** [file2] Error 1 > > scons: building terminated because of errors. > > > File1 > > 1 bad > > File2 > > 1 bad > > > ---- Iteration 1: file1 = 'good' > > 1 good > > scons: Reading SConscript files ... > > scons: done reading SConscript files. > > scons: Building targets ... > > scons: `file2' is up to date. > > scons: done building targets. > > > File1 > > 1 good > > File2 > > 1 bad > > ---------------------------------------------- >

1 0

Re: [Scons-users] Add arm64ec support on Visual Studio
by Joseph C. Brill July 13, 2025

July 13, 2025

See SCons discussion https://github.com/SCons/scons/discussions/4745 for some preliminary thoughts on first-class support for producing ARM64EC binaries with MSVC.

1 0

Add arm64ec support on Visual Studio
by Leonard de Ruijter July 12, 2025

July 12, 2025

Hi, Arm64ec is an architecture supported on Windows 11. In short, it runs smooth on arm64 processors without emulation, but it is compatible with x64. So you can load arm64ec dll's in x64 processes and vise versa, as long as you're on an arm64 host system. It is already possible to compile arm64ec on SCons by adding /ARM64EC to ccflags and /machine:arm64ec to linkflags. However I think it would be better to add arm64ec as a supported architecture directly in SCons itself, and it should append to ccflags and linkflags itself. Would you be open for a pull request that adds this? Cheers, Leoanrd

3 2

Re: [Scons-users] Scons-users Digest, Vol 165, Issue 10
by 于 June 9, 2025

June 9, 2025

Ok, I will try it. And I will reply you if theee's any?progress. ---- Replied Message ---- | From | scons-users-request(a)scons.org | | Date | 06/08/2025 13:35 | | To | scons-users(a)scons.org | | Cc | | | Subject | Scons-users Digest, Vol 165, Issue 10 | Send Scons-users mailing list submissions to scons-users(a)scons.org To subscribe or unsubscribe via the World Wide Web, visit https://pairlist4.pair.net/mailman/listinfo/scons-users or, via email, send a message with subject or body 'help' to scons-users-request(a)scons.org You can reach the person managing the list at scons-users-owner(a)scons.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Scons-users digest..." Today's Topics: 1. Re: Scons-users Digest, Vol 165, Issue 8 (Mats Wichmann) ---------------------------------------------------------------------- Message: 1 Date: Sat, 7 Jun 2025 06:16:33 -0600 From: Mats Wichmann <mats(a)wichmann.us> To: SCons users mailing list <scons-users(a)scons.org>, ? <yjtyzw(a)126.com> Subject: Re: [Scons-users] Scons-users Digest, Vol 165, Issue 8 Message-ID: <65407f3d-7340-4b8c-9181-53a870c82faa(a)wichmann.us> Content-Type: text/plain; charset=UTF-8; format=flowed On 6/7/25 04:55, ? wrote: > > ? ? could I use ninja to balance building time and dependencies? Yes, there are several ways to cut down build time, as long as you're prepared to accept some compromises. Letting SCons generate a ninja build file, and using ninja for builds most of the time, is fine. You can also use the --implicit-deps-unchanged option, which says not to rescan for dependencies. Both approaches work if you know you haven't changed the structure of the project, such that the dependencies might change. If they do, just rerun SCons normally (or in generate-ninja-file mode), and you can go back to using the speedups. There are some other tricks here: https://github.com/SCons/scons/wiki/GoFastButton ------------------------------ Subject: Digest Footer _______________________________________________ Scons-users mailing list Scons-users(a)scons.org https://pairlist4.pair.net/mailman/listinfo/scons-users ------------------------------ End of Scons-users Digest, Vol 165, Issue 10 ********************************************

1 0

Testing ninja build generator
by Julien Pommier June 8, 2025

June 8, 2025

Hi, I’m trying the ninja build generator (on macOS, with SCons 4.9.1), and have run so far into two small issues: - ninja build commands seem to be incorrectly generated for this type of SCons command, with two chained sub-commands: target = env.Command("run.sh", “run.sh.txt", [ Copy("$TARGET", "$SOURCE"), Chmod("$TARGET", 0o755) ]) - it looks like the http communication part between ninja and scons does not like whitespaces in target filenames, for example this command will fail: target = env.Textfile("run me.sh", “foobar"); the error is: File "/opt/homebrew/Cellar/python(a)3.12/3.12.9/Frameworks/Python.framework/Versions/3.12/lib/python3.12/http/client.py", line 1283, in _validate_path raise InvalidURL(f"URL can't contain control characters. {url!r} " http.client.InvalidURL: URL can't contain control characters. '/?build=run me.sh' (found at least ' ') ninja: build stopped: subcommand failed.scons: *** [build.ninja] CalledProcessError : Command 'ninja' returned non-zero exit status 1. Irrelevant to this bug report: I’ve been using scons for maybe 20 years, and I’m still very happy with my initial choice of using SCons. It is powerful, it is reliable, its cache is great. Thanks for this wonderful piece of software. Best regards, Julien

3 9