makes the build system compile on 32 bit systems
bonus, also fix incorrectly passing advanced debug options to the maker
process which doesn't care about them
On 32-bit systems usize is not u64 but it was assumed in multiple places
of the build script.
Sometimes using u64 instead of usize since available and used memory can
exceed usize on 32-bit systems (just like totalSystemMemory)
Example errors:
lib/compiler/build_runner.zig:508:26: error: expected type 'usize', found 'u64'
.available_rss = max_rss,
^~~~~~~
lib/compiler/build_runner.zig:508:26: note: unsigned 32-bit int cannot represent all possible unsigned 64-bit values
referenced by:
callMain [inlined]: lib/std/start.zig:699:88
callMainWithArgs [inlined]: lib/std/start.zig:638:20
posixCallMainAndExit: lib/std/start.zig:590:38
2 reference(s) hidden; use '-freference-trace=5' to see all references
lib/std/Build/WebServer.zig:849:38: error: expected type 'usize', found 'u64'
const buf = gpa.realloc(old_buf, new_len) catch @panic("out of memory");
^~~~~~~
lib/std/Build/WebServer.zig:849:38: note: unsigned 32-bit int cannot represent all possible unsigned 64-bit values
lib/std/mem/Allocator.zig:399:58: note: parameter type declared here
pub fn realloc(self: Allocator, old_mem: anytype, new_n: usize) Error!@TypeOf(old_mem) {
^~~~~
build.zig:548:10: error: type 'usize' cannot represent integer value '9300000000'
.max_rss = 9_300_000_000,
~^~~~~~~~~~~~~~~~~~~~~~~
build.zig:778:10: error: type 'usize' cannot represent integer value '8000000000'
.max_rss = 8_000_000_000,
~^~~~~~~~~~~~~~~~~~~~~~~
- choose smp_allocator depending on optimization mode
- organize the globals
- avoid pessimistically allocating failed command string
- recover the PkgConfig memory
- recover the memory from captureChildProcess
- make Step.result_stderr gpa-owned so it doesn't leak when a step that
fails with stderr is re-run
- recover memory from evalZigTest and evalGeneric child process stdio
streams
I'm a bit confused because my understanding is that each step is
supposed to make its own decision about whether to clear its watch
inputs and start over, or retain them from the previous update. However,
without this fix in place, the problem from #35224 manifests itself
again.
Since this fix is in place in master branch, I'll leave it for now and
audit the file watching logic later.
There is no concept of a "build runner" any more; it has been split in two:
configurer and maker.
Users of this feature will likely want to no longer override any logic, and
instead consume the configuration file produced by configurer.
If overriding one or the other of these is desired, the feature will need to be
re-introduced (as --override-maker or --override-configurer).
Not sure what I was thinking. This is silly, translate-c package simply
needs to pass this data (link_libc and target) to the CLI application,
which can then do the appropriate behavior.
pentuppup