Nixyri/zig
1
0
Fork 0
mirror of https://github.com/ziglang/zig.git synced 2024-11-14 16:13:24 +00:00
Code Issues Packages Projects Releases Wiki Activity
755f50a986
zig/build.zig

1216 lines
46 KiB
Zig
Raw Normal View History

self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
const std = @import("std");
stage2: improvements aimed at std lib integration * AstGen: emit decl lookup ZIR instructions rather than directly looking up decls in AstGen. This is necessary because we want to reuse the same immutable ZIR code for multiple generic instantiations (and comptime function calls). * AstGen: fix using members_len instead of fields_len for struct decls. * structs: the struct_decl ZIR instruction is now also a block. This is so that the type expressions, default field value expressions, and alignment expressions can be evaluated in a scope that contains the decls from the struct namespace itself. * Add "std" and "builtin" packages to the builtin package. * Don't try to build glibc, musl, or mingw-w64 when using `-ofmt=c`. * builtin.zig is generated without `usingnamespace`. * builtin.zig takes advantage of `std.zig.fmtId` for CPU features. * A first pass at implementing `usingnamespace`. It's problematic and should either be deleted, or polished, before merging this branch. * Sema: allow explicitly specifying the namespace in which to look up Decls. This is used by `struct_decl` in order to put the decls from the struct namespace itself in scope when evaluating the type expressions, default value expressions, and alignment expressions. * Module: fix `analyzeNamespace` assuming that it is the top-level root declaration node. * Sema: implement comptime and runtime cmp operator. * Sema: implement peer type resolution for enums and enum literals. * Pull in the changes from master branch: 262e09c482d98a78531c049a18b7f24146fe157f. * ZIR: complete out simple_ptr_type debug printing
2021-04-12 23:44:51 +00:00
const builtin = std.builtin;
self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
const Builder = std.build.Builder;
convert compare-output tests to use zig build system
2017-04-19 05:13:15 +00:00
const tests = @import("test/tests.zig");
self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
const BufMap = std.BufMap;
const mem = std.mem;
const ArrayList = std.ArrayList;
const io = std.io;
clean up references to os
2019-05-26 17:17:34 +00:00
const fs = std.fs;
move some of the installation from cmake to zig build This moves the installation of shipped source files from large CMakeLists.txt lists to zig build recursive directory installation. On my computer a cmake `make install` takes 2.4 seconds even when it has to do nothing, and prints a lot of unnecessary lines to stdout that say "up-to-date: [some file it is installing]". After this commit, the default output of `make` is down to 1 second, and it does not print any junk to stdout. Further, a `make install` is no longer required and `make` is sufficient. This closes #2874. It also closes #2585. `make` now always invokes `zig build` for installing files and libuserland.a, and zig's own caching system makes that go fast.
2019-07-14 07:06:20 +00:00
const InstallDirectoryOptions = std.build.InstallDirectoryOptions;
start moving `zig cc` to stage2 * build.zig: repair the ability to link against llvm, clang, and lld * move the zig cc arg parsing logic to stage2 - the preprocessor flag is still TODO - the clang arg iterator code is improved to use slices instead of raw pointers because it no longer has to deal with an extern struct. * clean up error printing with a `fatal` function and use log API for messages rather than std.debug.print * add support for more CLI options to stage2 & update usage text - hooking up most of these new options is TODO * clean up the way libc and libc++ are detected via command line options. target information is used to determine if any of the libc candidate names are chosen. * add native library directory detection * implement the ability to invoke clang from stage2 * introduce a build_options.have_llvm so we can comptime branch on whether LLVM is linked in or not.
2020-09-04 03:23:00 +00:00
const assert = std.debug.assert;
convert compare-output tests to use zig build system
2017-04-19 05:13:15 +00:00
start the 0.11.0 release cycle
2022-10-31 17:25:46 +00:00
const zig_version = std.builtin.Version{ .major = 0, .minor = 11, .patch = 0 };
build.zig: 32 MiB stack size This gives more headroom for comptime recursion, especially for debug builds of Zig.
2022-07-21 19:20:50 +00:00
const stack_size = 32 * 1024 * 1024;
stage2: implement zig version
2020-08-15 21:17:40 +00:00
use * for pointer type instead of & See #770 To help automatically translate code, see the zig-fmt-pointer-reform-2 branch. This will convert all & into *. Due to the syntax ambiguity (which is why we are making this change), even address-of & will turn into *, so you'll have to manually fix thes instances. You will be guaranteed to get compile errors for them - expected 'type', found 'foo'
2018-05-31 14:56:59 +00:00
pub fn build(b: *Builder) !void {
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
const release = b.option(bool, "release", "Build in release mode") orelse false;
const only_c = b.option(bool, "only-c", "Translate the Zig compiler to C code, with only the C backend enabled") orelse false;
build: introduce -Dwasi-bootstrap option Also, make -Donly-c prevent Autodoc from being included in the binary. This produces a 2.6 MiB zig.wasm file. 781 KB if piped through zstd.
2022-11-05 01:35:04 +00:00
const target = t: {
var default_target: std.zig.CrossTarget = .{};
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
if (only_c) {
build: introduce -Dwasi-bootstrap option Also, make -Donly-c prevent Autodoc from being included in the binary. This produces a 2.6 MiB zig.wasm file. 781 KB if piped through zstd.
2022-11-05 01:35:04 +00:00
default_target.ofmt = .c;
}
break :t b.standardTargetOptions(.{ .default_target = default_target });
};
const mode: std.builtin.Mode = if (release) switch (target.getCpuArch()) {
.wasm32 => .ReleaseSmall,
else => .ReleaseFast,
} else .Debug;
build.zig: fix single-threaded option Instead of defaulting to false, just keep the option as optional to communicate default to the build system. Fixes one problem with building the compiler for single-threaded targets.
2022-01-29 00:16:51 +00:00
const single_threaded = b.option(bool, "single-threaded", "Build artifacts that run in single threaded mode");
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
const use_zig_libcxx = b.option(bool, "use-zig-libcxx", "If libc++ is needed, use zig's bundled version, don't try to integrate with the system") orelse false;
self hosted zig: print usage
2017-10-21 21:31:06 +00:00
build: introduce -Dwasi-bootstrap option Also, make -Donly-c prevent Autodoc from being included in the binary. This produces a 2.6 MiB zig.wasm file. 781 KB if piped through zstd.
2022-11-05 01:35:04 +00:00
const test_step = b.step("test", "Run all the tests");
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
const docgen_exe = b.addExecutable("docgen", "doc/docgen.zig");
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
docgen_exe.single_threaded = single_threaded;
std.io: introduce buffered I/O and change API I started working on #465 and made some corresponding std.io API changes. New structs: * std.io.FileInStream * std.io.FileOutStream * std.io.BufferedOutStream * std.io.BufferedInStream Removed: * std.io.File.in_stream * std.io.File.out_stream Now instead of &file.out_stream or &file.in_stream to get access to the stream API for a file, you get it like this: var file_in_stream = io.FileInStream.init(&file); const in_stream = &file_in_stream.stream; var file_out_stream = io.FileOutStream.init(&file); const out_stream = &file_out_stream.stream; This is evidence that we might not need any OOP features - See #130.
2017-11-07 08:22:27 +00:00
clean up references to os
2019-05-26 17:17:34 +00:00
const rel_zig_exe = try fs.path.relative(b.allocator, b.build_root, b.zig_exe);
const langref_out_path = fs.path.join(
fixups, and modify std.mem.join and std.os.path.resolve API * zig fmt * std.mem.join takes a slice of slices instead of var args * std.mem.join takes a separator slice rather than byte, and always inserts it. Previously it would not insert the separator if there already was one, violating the documented behavior. * std.mem.join calculates exactly the correct amount to allocate and has no call to allocator.shrink() * bring back joinWindows and joinPosix and the corresponding tests. it is intended to be able to call these functions from any OS. * rename std.os.path.resolveSlice to resolve (now resolve takes a slice of slices instead of var args)
2019-02-07 05:42:41 +00:00
b.allocator,
remove type coercion from array values to references * Implements #3768. This is a sweeping breaking change that requires many (trivial) edits to Zig source code. Array values no longer coerced to slices; however one may use `&` to obtain a reference to an array value, which may then be coerced to a slice. * Adds `IrInstruction::dump`, for debugging purposes. It's useful to call to inspect the instruction when debugging Zig IR. * Fixes bugs with result location semantics. See the new behavior test cases, and compile error test cases. * Fixes bugs with `@typeInfo` not properly resolving const values. * Behavior tests are passing but std lib tests are not yet. There is more work to do before merging this branch.
2019-11-27 08:30:39 +00:00
&[_][]const u8{ b.cache_root, "langref.html" },
fixups, and modify std.mem.join and std.os.path.resolve API * zig fmt * std.mem.join takes a slice of slices instead of var args * std.mem.join takes a separator slice rather than byte, and always inserts it. Previously it would not insert the separator if there already was one, violating the documented behavior. * std.mem.join calculates exactly the correct amount to allocate and has no call to allocator.shrink() * bring back joinWindows and joinPosix and the corresponding tests. it is intended to be able to call these functions from any OS. * rename std.os.path.resolveSlice to resolve (now resolve takes a slice of slices instead of var args)
2019-02-07 05:42:41 +00:00
) catch unreachable;
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
const docgen_cmd = docgen_exe.run();
remove type coercion from array values to references * Implements #3768. This is a sweeping breaking change that requires many (trivial) edits to Zig source code. Array values no longer coerced to slices; however one may use `&` to obtain a reference to an array value, which may then be coerced to a slice. * Adds `IrInstruction::dump`, for debugging purposes. It's useful to call to inspect the instruction when debugging Zig IR. * Fixes bugs with result location semantics. See the new behavior test cases, and compile error test cases. * Fixes bugs with `@typeInfo` not properly resolving const values. * Behavior tests are passing but std lib tests are not yet. There is more work to do before merging this branch.
2019-11-27 08:30:39 +00:00
docgen_cmd.addArgs(&[_][]const u8{
docgen: support executing exe code examples See #465
2018-01-17 06:50:35 +00:00
rel_zig_exe,
clean up references to os
2019-05-26 17:17:34 +00:00
"doc" ++ fs.path.sep_str ++ "langref.html.in",
fix zig build cache dir path
2018-09-12 15:49:46 +00:00
langref_out_path,
std.io: introduce buffered I/O and change API I started working on #465 and made some corresponding std.io API changes. New structs: * std.io.FileInStream * std.io.FileOutStream * std.io.BufferedOutStream * std.io.BufferedInStream Removed: * std.io.File.in_stream * std.io.File.out_stream Now instead of &file.out_stream or &file.in_stream to get access to the stream API for a file, you get it like this: var file_in_stream = io.FileInStream.init(&file); const in_stream = &file_in_stream.stream; var file_out_stream = io.FileOutStream.init(&file); const out_stream = &file_out_stream.stream; This is evidence that we might not need any OOP features - See #130.
2017-11-07 08:22:27 +00:00
});
docgen_cmd.step.dependOn(&docgen_exe.step);
const docs_step = b.step("docs", "Build documentation");
docs_step.dependOn(&docgen_cmd.step);
ZIG_EXE envirnoment variable instead of testing build options No longer introduce build options for tests. Instead, ZIG_EXE environment variable is added to any invocation of `zig run` or `zig test`. The end result of this branch is the same: there is no longer a mandatory positional command line argument when invoking zig test binaries directly.
2022-09-14 21:56:45 +00:00
const test_cases = b.addTest("src/test.zig");
CLI: more careful resolution of paths In general, we prefer compiler code to use relative paths based on open directory handles because this is the most portable. However, sometimes absolute paths are used, and sometimes relative paths are used that go up a directory. The recent improvements in 81d2135ca6ebd71b8c121a19957c8fbf7f87125b regressed the use case when an absolute path is used for the zig lib directory mixed with a relative path used for the root source file. This could happen when, for example, running the standard library tests, like this: stage3/bin/zig test ../lib/std/std.zig This happened because the zig lib dir was inferred to be an absolute directory based on the zig executable directory, while the root source file was detected as a relative path. There was no common prefix and so it was not determined that the std.zig file was inside the lib directory. This commit adds a function for resolving paths that preserves relative path names while allowing absolute paths, and converting relative upwards paths (e.g. "../foo") to absolute paths. This restores the previous functionality while remaining compatible with systems such as WASI that cannot deal with absolute paths.
2022-11-26 00:12:50 +00:00
test_cases.main_pkg_path = ".";
build.zig: 32 MiB stack size This gives more headroom for comptime recursion, especially for debug builds of Zig.
2022-07-21 19:20:50 +00:00
test_cases.stack_size = stack_size;
migrate runtime safety tests to the new test harness * migrate runtime safety tests to the new test harness - this required adding compare output / execution support for stage1 to the test harness. * rename `zig build test-stage2` to `zig build test-cases` since it now does quite a bit of stage1 testing actually. I named it this way since the main directory in the source tree associated with these tests is "test/cases/". * add some documentation for the test manifest format.
2022-05-13 07:00:20 +00:00
test_cases.setBuildMode(mode);
test_cases.single_threaded = single_threaded;
self-hosted build: use llvm-config from stage1
2018-01-04 02:32:50 +00:00
remove type coercion from array values to references * Implements #3768. This is a sweeping breaking change that requires many (trivial) edits to Zig source code. Array values no longer coerced to slices; however one may use `&` to obtain a reference to an array value, which may then be coerced to a slice. * Adds `IrInstruction::dump`, for debugging purposes. It's useful to call to inspect the instruction when debugging Zig IR. * Fixes bugs with result location semantics. See the new behavior test cases, and compile error test cases. * Fixes bugs with `@typeInfo` not properly resolving const values. * Behavior tests are passing but std lib tests are not yet. There is more work to do before merging this branch.
2019-11-27 08:30:39 +00:00
const fmt_build_zig = b.addFmt(&[_][]const u8{"build.zig"});
add builder.addFmt API and use it to test stage1 zig fmt closes #1968
2019-02-26 23:10:40 +00:00
ci: drone disable debug test suite for aarch64 Temporary workaround for #8597 until upstream fix lands. - add `zig build -Dskip-debug` option - build a release-fast build.exe - disable test suite build modes { debug, release-small, release-safe } - enable passing test-* components - use parallel pipeline steps for tests
2021-04-24 20:39:26 +00:00
const skip_debug = b.option(bool, "skip-debug", "Main test suite skips debug builds") orelse false;
build system: add -Dskip-release option to test faster
2018-07-11 18:09:05 +00:00
const skip_release = b.option(bool, "skip-release", "Main test suite skips release builds") orelse false;
ci: skip release-small tests to save time we keep hitting the limit on how long CI tests take to run.
2018-09-12 18:50:26 +00:00
const skip_release_small = b.option(bool, "skip-release-small", "Main test suite skips release-small builds") orelse skip_release;
const skip_release_fast = b.option(bool, "skip-release-fast", "Main test suite skips release-fast builds") orelse skip_release;
const skip_release_safe = b.option(bool, "skip-release-safe", "Main test suite skips release-safe builds") orelse skip_release;
slice types no longer have field access * fix crash when doing field access of slice types. closes #2486 * remove the deprecated Child property from slice types * add -Dskip-non-native build option to build script
2019-05-15 01:21:59 +00:00
const skip_non_native = b.option(bool, "skip-non-native", "Main test suite skips non-native builds") orelse false;
significantly increase test coverage * add zig build option `-Dskip-libc` to skip tests that build libc (e.g. if you don't want to wait for musl to build) * add `-Denable-wine` option which uses wine to run cross compiled windows tests on non-windows hosts * add `-Denable-qemu` option which uses qemu to run cross compiled foreign architecture tests * add `-Denable-foreign-glibc=path` option which combined with `-Denable-qemu` enables running cross compiled tests that link against glibc. See https://github.com/ziglang/zig/wiki/Updating-libc#glibc for how to produce this directory. * the test matrix is done manually. release test builds are only enabled by default for the native target. this should save us some CI time, while still providing decent coverage of release builds. - add test coverage for `x86_64-linux-musl -lc` (building musl libc) - add test coverage for `x86_64-linux-gnu -lc` (building glibc) - add test coverage for `aarch64v8_5a-linux-none` - add test coverage for `aarch64v8_5a-linux-musl -lc` (building musl libc) - add test coverage for `aarch64v8_5a-linux-gnu -lc` (building glibc) - add test coverage for `arm-linux-none` - test coverage for `arm-linux-musleabihf -lc` (building musl libc) is disabled due to #3286 - test coverage for `arm-linux-gnueabihf -lc` (building glibc) is disabled due to #3287 - test coverage for `x86_64-windows-gnu -lc` (building mingw-w64) is disabled due to #3285 * enable qemu testing on the Linux CI job. There's not really a good reason to enable wine, since we have a Windows CI job as well. * remove the no longer needed `--build-file ../build.zig` from CI scripts * fix bug in glibc compilation where it wasn't properly reading the abi list txt files, resulting in "key not found" error. * std.build.Target gains: - isNetBSD - isLinux - osRequiresLibC - getArchPtrBitWidth - getExternalExecutor * zig build system gains support for enabling wine and enabling qemu. `artifact.enable_wine = true;`, `artifact.enable_qemu = true;`. This communicates that the system has these tools installed and the build system will use them to run tests. * zig build system gains support for overriding the dynamic linker of an executable artifact. * fix std.c.lseek prototype. makes behavior tests for arm-linux-musleabihf pass. * disable std lib tests that are failing on ARM. See #3288, #3289 * provide `std.os.off_t`. * disable some of the compiler_rt symbols for arm 32 bit. Fixes compiler_rt tests for arm 32 bit * add __stack_chk_guard when linking against glibc. Fixes std lib tests for aarch64-linux-gnu * workaround for "unable to inline function" using `@inlineCall`. Fixes compiler_rt tests for arm 32 bit.
2019-09-22 03:55:56 +00:00
const skip_libc = b.option(bool, "skip-libc", "Main test suite skips tests that link libc") orelse false;
CI: skip single-threaded tests on Drone sure would be nice if they would just give us another hour of CI run time.
2022-06-01 21:05:58 +00:00
const skip_single_threaded = b.option(bool, "skip-single-threaded", "Main test suite skips tests that are single-threaded") orelse false;
test harness improvements * `-Dskip-compile-errors` is removed; `-Dskip-stage1` is added. * Use `std.testing.allocator` instead of a new instance of GPA. - Fix the memory leaks this revealed. * Show the file name when it is not parsed correctly such as when the manifest is missing. - Better error messages when test files are not parsed correctly. * Ignore unknown files such as swap files. * Move logic from declarative file to the test harness implementation. * Move stage1 tests to stage2 tests where appropriate.
2022-03-31 22:06:44 +00:00
const skip_stage1 = b.option(bool, "skip-stage1", "Main test suite skips stage1 compile error tests") orelse false;
ci: aarch64-linux: disable run-translated-c tests See #8537
2021-04-15 06:10:51 +00:00
const skip_run_translated_c = b.option(bool, "skip-run-translated-c", "Main test suite skips run-translated-c tests") orelse false;
ci: drone: disable stage2 tests See #8545
2021-04-15 23:20:43 +00:00
const skip_stage2_tests = b.option(bool, "skip-stage2-tests", "Main test suite skips self-hosted compiler tests") orelse false;
build: rename the "skip lib files" option * Old cmake option: `-DZIG_SKIP_INSTALL_LIB_FILES=ON` * New cmake option: `-DZIG_NO_LIB=ON` * Old build.zig option: `-Dskip-install-lib-files` * New build.zig option: `-Dno-lib` Motivation is making build commands easier to type.
2022-10-27 22:16:14 +00:00
const deprecated_skip_install_lib_files = b.option(bool, "skip-install-lib-files", "deprecated. see no-lib") orelse false;
if (deprecated_skip_install_lib_files) {
std.log.warn("-Dskip-install-lib-files is deprecated in favor of -Dno-lib", .{});
}
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
const skip_install_lib_files = b.option(bool, "no-lib", "skip copying of lib/ files to installation prefix. Useful for development") orelse deprecated_skip_install_lib_files;
self hosted zig: print usage
2017-10-21 21:31:06 +00:00
move some of the installation from cmake to zig build This moves the installation of shipped source files from large CMakeLists.txt lists to zig build recursive directory installation. On my computer a cmake `make install` takes 2.4 seconds even when it has to do nothing, and prints a lot of unnecessary lines to stdout that say "up-to-date: [some file it is installing]". After this commit, the default output of `make` is down to 1 second, and it does not print any junk to stdout. Further, a `make install` is no longer required and `make` is sufficient. This closes #2874. It also closes #2585. `make` now always invokes `zig build` for installing files and libuserland.a, and zig's own caching system makes that go fast.
2019-07-14 07:06:20 +00:00
const only_install_lib_files = b.option(bool, "lib-files-only", "Only install library files") orelse false;
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
const static_llvm = b.option(bool, "static-llvm", "Disable integration with system-installed LLVM, Clang, LLD, and libc++") orelse false;
remove `-fstage1` option After this commit, the self-hosted compiler does not offer the option to use stage1 as a backend anymore.
2022-11-01 03:29:55 +00:00
const enable_llvm = b.option(bool, "enable-llvm", "Build self-hosted compiler with LLVM backend enabled") orelse static_llvm;
stage2: update LLVM backend to for LLVM 13 There was some new code in master branch enumerating all the targets and a new target was added so we needed to add the glue code. This commit also introduces some build options to support experimental LLVM targets.
2021-09-01 05:50:10 +00:00
const llvm_has_m68k = b.option(
bool,
"llvm-has-m68k",
"Whether LLVM has the experimental target m68k enabled",
) orelse false;
const llvm_has_csky = b.option(
bool,
"llvm-has-csky",
"Whether LLVM has the experimental target csky enabled",
) orelse false;
const llvm_has_arc = b.option(
bool,
"llvm-has-arc",
"Whether LLVM has the experimental target arc enabled",
) orelse false;
Add -Denable-macos-sdk explicit flag to build.zig This way, we can explicitly signal if a test requires the presence of macOS SDK to build. For instance, when testing our in-house MachO linker for correctly linking Objective-C, we require the presence of the SDK on the host system, and we can enforce this with `-Denable-macos-sdk` flag to `zig build test-standalone`.
2021-08-02 08:04:54 +00:00
const enable_macos_sdk = b.option(bool, "enable-macos-sdk", "Run tests requiring presence of macOS SDK and frameworks") orelse false;
Update build.zig
2022-11-28 21:04:42 +00:00
const enable_symlinks_windows = b.option(bool, "enable-symlinks-windows", "Run tests requiring presence of symlinks on Windows") orelse false;
don't try to find config_h if it's not needed
2020-07-04 01:15:01 +00:00
const config_h_path_option = b.option([]const u8, "config_h", "Path to the generated config.h");
build.zig supports specifying config.h location explicitly also it does not try to run llvm-config executable when -Dlib-files-only This fixes cross-compiling using the bootstrap repository.
2020-04-06 17:07:19 +00:00
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00:00
if (!skip_install_lib_files) {
b.installDirectory(InstallDirectoryOptions{
.source_dir = "lib",
make remaining enums in build.zig snake_case
2021-06-11 08:50:48 +00:00
.install_dir = .lib,
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00:00
.install_subdir = "zig",
.exclude_extensions = &[_][]const u8{
update gitattributes and move test data into subdir
2022-12-18 23:28:30 +00:00
// exclude files from lib/std/compress/testdata
compress: add a deflate compressor Replaces the inflate API from `inflateStream(reader: anytype, window_slice: []u8)` to `decompressor(allocator: mem.Allocator, reader: anytype, dictionary: ?[]const u8)` and `compressor(allocator: mem.Allocator, writer: anytype, options: CompressorOptions)`
2022-01-09 01:12:00 +00:00
".gz",
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00:00
".z.0",
".z.9",
"rfc1951.txt",
compress: add a deflate compressor Replaces the inflate API from `inflateStream(reader: anytype, window_slice: []u8)` to `decompressor(allocator: mem.Allocator, reader: anytype, dictionary: ?[]const u8)` and `compressor(allocator: mem.Allocator, writer: anytype, options: CompressorOptions)`
2022-01-09 01:12:00 +00:00
"rfc1952.txt",
// exclude files from lib/std/compress/deflate/testdata
".expect",
".expect-noinput",
".golden",
".input",
"compress-e.txt",
"compress-gettysburg.txt",
"compress-pi.txt",
"rfc1951.txt",
// exclude files from lib/std/tz/
tz parsing reader interface, test thicc files, and exclude tzif
2021-12-31 17:17:49 +00:00
".tzif",
compress: add a deflate compressor Replaces the inflate API from `inflateStream(reader: anytype, window_slice: []u8)` to `decompressor(allocator: mem.Allocator, reader: anytype, dictionary: ?[]const u8)` and `compressor(allocator: mem.Allocator, writer: anytype, options: CompressorOptions)`
2022-01-09 01:12:00 +00:00
// others
"README.md",
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00:00
},
build.zig: blank out "*test.zig" files instead of omit Now that `@import` of a non-existent file name is a compile error, the Zig installation needs to include files that end with test.zig. However we still want to avoid bloat in the installation size, so we blank them out instead of omitting them entirely. Now AstGen of the full standard library can complete successfully on a Zig installation rather than erroring out with file not found.
2021-05-19 00:18:42 +00:00
.blank_extensions = &[_][]const u8{
"test.zig",
},
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00:00
});
}
self hosted zig: print usage
2017-10-21 21:31:06 +00:00
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
if (only_install_lib_files)
return;
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 00:17:37 +00:00
const tracy = b.option([]const u8, "tracy", "Enable Tracy integration. Supply path to Tracy source");
build: update Tracy integration * Update for v0.9 * Enable the memory and callstack integrations by default
2022-10-27 01:17:49 +00:00
const tracy_callstack = b.option(bool, "tracy-callstack", "Include callstack information with Tracy data. Does nothing if -Dtracy is not provided") orelse (tracy != null);
const tracy_allocation = b.option(bool, "tracy-allocation", "Include allocation information with Tracy data. Does nothing if -Dtracy is not provided") orelse (tracy != null);
add option to force usage of `GeneralPurposeAllocator`
2022-01-23 20:10:39 +00:00
const force_gpa = b.option(bool, "force-gpa", "Force the compiler to use GeneralPurposeAllocator") orelse false;
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
const link_libc = b.option(bool, "force-link-libc", "Force self-hosted compiler to link libc") orelse (enable_llvm or only_c);
build: add -Dsanitize-thread option
2022-10-05 10:22:10 +00:00
const sanitize_thread = b.option(bool, "sanitize-thread", "Enable thread-sanitization") orelse false;
build: introduce -Dwasi-bootstrap option Also, make -Donly-c prevent Autodoc from being included in the binary. This produces a 2.6 MiB zig.wasm file. 781 KB if piped through zstd.
2022-11-05 01:35:04 +00:00
const strip = b.option(bool, "strip", "Omit debug information");
stage2: use std.debug.Trace only when explicitly enabled Because it bumps up the stack space requirements, which is making a test case fail on aarch64 drone CI.
2022-06-09 22:33:04 +00:00
const value_tracing = b.option(bool, "value-tracing", "Enable extra state tracking to help troubleshoot bugs in the compiler (using the std.debug.Trace API)") orelse false;
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 00:17:37 +00:00
build.zig: add -Dmem-leak-frames option to configure how many stack frames to save with every allocation, in case it leaks and needs to get printed on process termination.
2021-05-04 03:42:36 +00:00
const mem_leak_frames: u32 = b.option(u32, "mem-leak-frames", "How many stack frames to print when a memory leak occurs. Tests get 2x this amount.") orelse blk: {
build: introduce -Dwasi-bootstrap option Also, make -Donly-c prevent Autodoc from being included in the binary. This produces a 2.6 MiB zig.wasm file. 781 KB if piped through zstd.
2022-11-05 01:35:04 +00:00
if (strip == true) break :blk @as(u32, 0);
build.zig: add -Dmem-leak-frames option to configure how many stack frames to save with every allocation, in case it leaks and needs to get printed on process termination.
2021-05-04 03:42:36 +00:00
if (mode != .Debug) break :blk 0;
break :blk 4;
};
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
const exe = addCompilerStep(b);
build.zig: expose a strip option
2021-02-24 23:36:27 +00:00
exe.strip = strip;
build: add -Dsanitize-thread option
2022-10-05 10:22:10 +00:00
exe.sanitize_thread = sanitize_thread;
build: include a build-id note only if explicitly requested
2022-05-31 20:51:59 +00:00
exe.build_id = b.option(bool, "build-id", "Include a build id note") orelse false;
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
exe.install();
exe.setBuildMode(mode);
exe.setTarget(target);
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
const compile_step = b.step("compile", "Build the self-hosted compiler");
compile_step.dependOn(&exe.step);
build: make -Dskip-stage2-tests not build stage2 for the test-toolchain step
2021-09-16 18:21:19 +00:00
if (!skip_stage2_tests) {
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(&exe.step);
build: make -Dskip-stage2-tests not build stage2 for the test-toolchain step
2021-09-16 18:21:19 +00:00
}
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
b.default_step.dependOn(&exe.step);
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
exe.single_threaded = single_threaded;
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
if (target.isWindows() and target.getAbi() == .gnu) {
// LTO is currently broken on mingw, this can be removed when it's fixed.
exe.want_lto = false;
migrate runtime safety tests to the new test harness * migrate runtime safety tests to the new test harness - this required adding compare output / execution support for stage1 to the test harness. * rename `zig build test-stage2` to `zig build test-cases` since it now does quite a bit of stage1 testing actually. I named it this way since the main directory in the source tree associated with these tests is "test/cases/". * add some documentation for the test manifest format.
2022-05-13 07:00:20 +00:00
test_cases.want_lto = false;
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
}
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
const exe_options = b.addOptions();
exe.addOptions("build_options", exe_options);
exe_options.addOption(u32, "mem_leak_frames", mem_leak_frames);
exe_options.addOption(bool, "skip_non_native", skip_non_native);
exe_options.addOption(bool, "have_llvm", enable_llvm);
stage2: update LLVM backend to for LLVM 13 There was some new code in master branch enumerating all the targets and a new target was added so we needed to add the glue code. This commit also introduces some build options to support experimental LLVM targets.
2021-09-01 05:50:10 +00:00
exe_options.addOption(bool, "llvm_has_m68k", llvm_has_m68k);
exe_options.addOption(bool, "llvm_has_csky", llvm_has_csky);
exe_options.addOption(bool, "llvm_has_arc", llvm_has_arc);
add option to force usage of `GeneralPurposeAllocator`
2022-01-23 20:10:39 +00:00
exe_options.addOption(bool, "force_gpa", force_gpa);
build: add `-Donly-c` option This option can be used to produce a C backend build of the self-hosted compiler, which only has the C backend enabled. Once the C backend is capable of self-hosting, this will be a way for us to replace our stage1 codebase with a C backend build of self-hosted, which we can then use for bootstrapping. See #5246 for more details. Using this option right now results in a crash because the C backend is not yet passing all the behavior tests.
2022-10-23 20:18:22 +00:00
exe_options.addOption(bool, "only_c", only_c);
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
if (link_libc) {
exe.linkLibC();
migrate runtime safety tests to the new test harness * migrate runtime safety tests to the new test harness - this required adding compare output / execution support for stage1 to the test harness. * rename `zig build test-stage2` to `zig build test-cases` since it now does quite a bit of stage1 testing actually. I named it this way since the main directory in the source tree associated with these tests is "test/cases/". * add some documentation for the test manifest format.
2022-05-13 07:00:20 +00:00
test_cases.linkLibC();
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
}
stage2: make --debug-log work by default for debug builds can be disabled with `-Dlog=false`
2022-02-01 04:11:41 +00:00
const is_debug = mode == .Debug;
const enable_logging = b.option(bool, "log", "Enable debug logging with --debug-log") orelse is_debug;
macho: dump linker's state as JSON Each element of the output JSON has the VM address of the generated binary nondecreasing (some elements might occupy the same VM address for example the atom and the relocation might coincide in the address space). The generated JSON can be inspected manually or via a preview tool `zig-snapshots` that I am currently working on and will allow the user to inspect interactively the state of the linker together with the positioning of sections, symbols, atoms and relocations within each snapshot state, and in the future, between snapshots too. This should allow for quicker debugging of the linker which is nontrivial when run in the incremental mode. Note that the state will only be dumped if the compiler is built with `-Dlink-snapshot` flag on, and then the compiler is passed `--debug-link-snapshot` flag upon compiling a source/project.
2021-10-14 11:50:10 +00:00
const enable_link_snapshots = b.option(bool, "link-snapshot", "Whether to enable linker state snapshots") orelse false;
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
const opt_version_string = b.option([]const u8, "version-string", "Override Zig version string. Default is to find out with git.");
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
const version_slice = if (opt_version_string) |version| version else v: {
Avoid depending on child process execution when not supported by host OS In accordance with the requesting issue (#10750): - `zig test` skips any tests that it cannot spawn, returning success - `zig run` and `zig build` exit with failure, reporting the command the cannot be run - `zig clang`, `zig ar`, etc. already punt directly to the appropriate clang/lld main(), even before this change - Native `libc` Detection is not supported Additionally, `exec()` and related Builder functions error at run-time, reporting the command that cannot be run
2022-02-03 22:27:01 +00:00
if (!std.process.can_spawn) {
std.debug.print("error: version info cannot be retrieved from git. Zig version must be provided using -Dversion-string\n", .{});
std.process.exit(1);
}
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
const version_string = b.fmt("{d}.{d}.{d}", .{ zig_version.major, zig_version.minor, zig_version.patch });
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
var code: u8 = undefined;
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
const git_describe_untrimmed = b.execAllowFail(&[_][]const u8{
"git", "-C", b.build_root, "describe", "--match", "*.*.*", "--tags",
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
}, &code, .Ignore) catch {
break :v version_string;
};
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
const git_describe = mem.trim(u8, git_describe_untrimmed, " \n\r");
switch (mem.count(u8, git_describe, "-")) {
0 => {
Release 0.10.0
2022-10-31 17:24:38 +00:00
// Tagged release version (e.g. 0.10.0).
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
if (!mem.eql(u8, git_describe, version_string)) {
tests: Use {s} instead of {} when formatting strings
2020-11-26 12:28:38 +00:00
std.debug.print("Zig version '{s}' does not match Git tag '{s}'\n", .{ version_string, git_describe });
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
std.process.exit(1);
}
break :v version_string;
},
2 => {
Release 0.10.0
2022-10-31 17:24:38 +00:00
// Untagged development build (e.g. 0.10.0-dev.2025+ecf0050a9).
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 09:01:47 +00:00
var it = mem.split(u8, git_describe, "-");
std.mem: add `first` method to `SplitIterator` and `SplitBackwardsIterator`
2022-07-25 19:04:30 +00:00
const tagged_ancestor = it.first();
const commit_height = it.next().?;
const commit_id = it.next().?;
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
const ancestor_ver = try std.builtin.Version.parse(tagged_ancestor);
if (zig_version.order(ancestor_ver) != .gt) {
std.debug.print("Zig version '{}' must be greater than tagged ancestor '{}'\n", .{ zig_version, ancestor_ver });
std.process.exit(1);
}
// Check that the commit hash is prefixed with a 'g' (a Git convention).
if (commit_id.len < 1 or commit_id[0] != 'g') {
tests: Use {s} instead of {} when formatting strings
2020-11-26 12:28:38 +00:00
std.debug.print("Unexpected `git describe` output: {s}\n", .{git_describe});
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
break :v version_string;
}
// The version is reformatted in accordance with the https://semver.org specification.
tests: Use {s} instead of {} when formatting strings
2020-11-26 12:28:38 +00:00
break :v b.fmt("{s}-dev.{s}+{s}", .{ version_string, commit_height, commit_id[1..] });
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
},
else => {
tests: Use {s} instead of {} when formatting strings
2020-11-26 12:28:38 +00:00
std.debug.print("Unexpected `git describe` output: {s}\n", .{git_describe});
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
break :v version_string;
},
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
}
};
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
const version = try b.allocator.dupeZ(u8, version_slice);
exe_options.addOption([:0]const u8, "version", version);
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
if (enable_llvm) {
build.zig: Emit warning if "config.h" cannot be found We now warn the user if config.h could not be located. This also updates the search to stop early upon encountering a `.git` directory, so that we avoid recursing outside of the zig source if possible.
2022-07-16 00:25:38 +00:00
const cmake_cfg = if (static_llvm) null else blk: {
if (findConfigH(b, config_h_path_option)) |config_h_path| {
const file_contents = fs.cwd().readFileAlloc(b.allocator, config_h_path, max_config_h_bytes) catch unreachable;
break :blk parseConfigH(b, file_contents);
} else {
std.log.warn("config.h could not be located automatically. Consider providing it explicitly via \"-Dconfig_h\"", .{});
break :blk null;
}
};
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
if (cmake_cfg) |cfg| {
// Inside this code path, we have to coordinate with system packaged LLVM, Clang, and LLD.
// That means we also have to rely on stage1 compiled c++ files. We parse config.h to find
// the information passed on to us from cmake.
if (cfg.cmake_prefix_path.len > 0) {
build.zig: Parse CMAKE_PREFIX_PATH with multiple entries CMAKE_PREFIX_PATH is a semicolon separated list.
2022-10-11 15:16:27 +00:00
var it = mem.tokenize(u8, cfg.cmake_prefix_path, ";");
while (it.next()) |path| {
b.addSearchPrefix(path);
}
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
}
try addCmakeCfgOptionsToExe(b, cfg, exe, use_zig_libcxx);
migrate runtime safety tests to the new test harness * migrate runtime safety tests to the new test harness - this required adding compare output / execution support for stage1 to the test harness. * rename `zig build test-stage2` to `zig build test-cases` since it now does quite a bit of stage1 testing actually. I named it this way since the main directory in the source tree associated with these tests is "test/cases/". * add some documentation for the test manifest format.
2022-05-13 07:00:20 +00:00
try addCmakeCfgOptionsToExe(b, cfg, test_cases, use_zig_libcxx);
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
} else {
// Here we are -Denable-llvm but no cmake integration.
try addStaticLlvmOptionsToExe(exe);
migrate runtime safety tests to the new test harness * migrate runtime safety tests to the new test harness - this required adding compare output / execution support for stage1 to the test harness. * rename `zig build test-stage2` to `zig build test-cases` since it now does quite a bit of stage1 testing actually. I named it this way since the main directory in the source tree associated with these tests is "test/cases/". * add some documentation for the test manifest format.
2022-05-13 07:00:20 +00:00
try addStaticLlvmOptionsToExe(test_cases);
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
}
build.zig: on windows always link llvm-required system libs When building with LLVM, always do -lole32 -lversion -luuid even when using the cmake-provided build stuff. Otherwise we get undefined symbols when linking.
2022-12-07 09:50:49 +00:00
if (target.isWindows()) {
inline for (.{ exe, test_cases }) |artifact| {
artifact.linkSystemLibrary("version");
artifact.linkSystemLibrary("uuid");
artifact.linkSystemLibrary("ole32");
}
}
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
}
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
const semver = try std.SemanticVersion.parse(version);
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
exe_options.addOption(std.SemanticVersion, "semver", semver);
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
exe_options.addOption(bool, "enable_logging", enable_logging);
macho: dump linker's state as JSON Each element of the output JSON has the VM address of the generated binary nondecreasing (some elements might occupy the same VM address for example the atom and the relocation might coincide in the address space). The generated JSON can be inspected manually or via a preview tool `zig-snapshots` that I am currently working on and will allow the user to inspect interactively the state of the linker together with the positioning of sections, symbols, atoms and relocations within each snapshot state, and in the future, between snapshots too. This should allow for quicker debugging of the linker which is nontrivial when run in the incremental mode. Note that the state will only be dumped if the compiler is built with `-Dlink-snapshot` flag on, and then the compiler is passed `--debug-link-snapshot` flag upon compiling a source/project.
2021-10-14 11:50:10 +00:00
exe_options.addOption(bool, "enable_link_snapshots", enable_link_snapshots);
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
exe_options.addOption(bool, "enable_tracy", tracy != null);
make tracy.zig more feature complete
2021-10-31 14:12:36 +00:00
exe_options.addOption(bool, "enable_tracy_callstack", tracy_callstack);
add functionality to trace allocations
2021-10-31 14:16:59 +00:00
exe_options.addOption(bool, "enable_tracy_allocation", tracy_allocation);
stage2: use std.debug.Trace only when explicitly enabled Because it bumps up the stack space requirements, which is making a test case fail on aarch64 drone CI.
2022-06-09 22:33:04 +00:00
exe_options.addOption(bool, "value_tracing", value_tracing);
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
if (tracy) |tracy_path| {
const client_cpp = fs.path.join(
b.allocator,
build: update Tracy integration * Update for v0.9 * Enable the memory and callstack integrations by default
2022-10-27 01:17:49 +00:00
&[_][]const u8{ tracy_path, "public", "TracyClient.cpp" },
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
) catch unreachable;
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
// On mingw, we need to opt into windows 7+ to get some features required by tracy.
const tracy_c_flags: []const []const u8 = if (target.isWindows() and target.getAbi() == .gnu)
&[_][]const u8{ "-DTRACY_ENABLE=1", "-fno-sanitize=undefined", "-D_WIN32_WINNT=0x601" }
else
&[_][]const u8{ "-DTRACY_ENABLE=1", "-fno-sanitize=undefined" };
Normalize some build function names An attempt to normalize some of the function names in build.zig. Normalize add*Dir to add*Path. Also use "Library" instead of the "Lib" abbreviation. The PR does not remove the old names, only adds the new normalized ones to faciliate a transition period.
2022-01-24 18:15:32 +00:00
exe.addIncludePath(tracy_path);
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
exe.addCSourceFile(client_cpp, tracy_c_flags);
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 00:17:37 +00:00
if (!enable_llvm) {
exe.linkSystemLibraryName("c++");
}
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
exe.linkLibC();
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
if (target.isWindows()) {
exe.linkSystemLibrary("dbghelp");
exe.linkSystemLibrary("ws2_32");
}
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
}
convert compare-output tests to use zig build system
2017-04-19 05:13:15 +00:00
const test_filter = b.option([]const u8, "test-filter", "Skip tests that do not match filter");
build.zig: rename a local variable
2022-05-13 21:30:43 +00:00
const test_cases_options = b.addOptions();
test_cases.addOptions("build_options", test_cases_options);
test_cases_options.addOption(bool, "enable_logging", enable_logging);
test_cases_options.addOption(bool, "enable_link_snapshots", enable_link_snapshots);
test_cases_options.addOption(bool, "skip_non_native", skip_non_native);
test_cases_options.addOption(bool, "skip_stage1", skip_stage1);
test_cases_options.addOption(bool, "have_llvm", enable_llvm);
test_cases_options.addOption(bool, "llvm_has_m68k", llvm_has_m68k);
test_cases_options.addOption(bool, "llvm_has_csky", llvm_has_csky);
test_cases_options.addOption(bool, "llvm_has_arc", llvm_has_arc);
multi-thread `zig build test-cases` Instead of always using std.testing.allocator, the test harness now follows the same logic as self-hosted for choosing an allocator - that is - it uses C allocator when linking libc, std.testing.allocator otherwise, and respects `-Dforce-gpa` to override the decision. I did this because I found GeneralPurposeAllocator to be prohibitively slow when doing multi-threading, even in the context of a debug build. There is now a second thread pool which is used to spawn each test case. The stage2 tests are passed the first thread pool. If it were only multi-threading the stage1 tests then we could use the same thread pool for everything. However, the problem with this strategy with stage2 is that stage2 wants to spawn tasks and then call wait() on the main thread. If we use the same thread pool for everything, we get a deadlock because all the threads end up all hanging at wait() and nothing is getting done. So we use our second thread pool to simulate a "process pool" of sorts. I spent most of the time working on this commit scratching my head trying to figure out why I was getting ETXTBSY when spawning the test cases. Turns out it's a fundamental Unix design flaw, already a known, unsolved issue by Go and Java maintainers: https://github.com/golang/go/issues/22315 https://bugs.openjdk.org/browse/JDK-8068370 With this change, the following command, executed on my laptop, went from 6m24s to 1m44s: ``` stage1/bin/zig build test-cases -fqemu -fwasmtime -Denable-llvm ``` closes #11818
2022-06-14 01:59:52 +00:00
test_cases_options.addOption(bool, "force_gpa", force_gpa);
build: add `-Donly-c` option This option can be used to produce a C backend build of the self-hosted compiler, which only has the C backend enabled. Once the C backend is capable of self-hosting, this will be a way for us to replace our stage1 codebase with a C backend build of self-hosted, which we can then use for bootstrapping. See #5246 for more details. Using this option right now results in a crash because the C backend is not yet passing all the behavior tests.
2022-10-23 20:18:22 +00:00
test_cases_options.addOption(bool, "only_c", only_c);
build.zig: rename a local variable
2022-05-13 21:30:43 +00:00
test_cases_options.addOption(bool, "enable_qemu", b.enable_qemu);
test_cases_options.addOption(bool, "enable_wine", b.enable_wine);
test_cases_options.addOption(bool, "enable_wasmtime", b.enable_wasmtime);
test_cases_options.addOption(bool, "enable_rosetta", b.enable_rosetta);
test_cases_options.addOption(bool, "enable_darling", b.enable_darling);
test_cases_options.addOption(u32, "mem_leak_frames", mem_leak_frames * 2);
stage2: use std.debug.Trace only when explicitly enabled Because it bumps up the stack space requirements, which is making a test case fail on aarch64 drone CI.
2022-06-09 22:33:04 +00:00
test_cases_options.addOption(bool, "value_tracing", value_tracing);
build.zig: rename a local variable
2022-05-13 21:30:43 +00:00
test_cases_options.addOption(?[]const u8, "glibc_runtimes_dir", b.glibc_runtimes_dir);
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
test_cases_options.addOption([:0]const u8, "version", version);
build.zig: rename a local variable
2022-05-13 21:30:43 +00:00
test_cases_options.addOption(std.SemanticVersion, "semver", semver);
test_cases_options.addOption(?[]const u8, "test_filter", test_filter);
stage2 tests: support the -Denable-qemu options and friends
2020-08-04 22:32:16 +00:00
migrate runtime safety tests to the new test harness * migrate runtime safety tests to the new test harness - this required adding compare output / execution support for stage1 to the test harness. * rename `zig build test-stage2` to `zig build test-cases` since it now does quite a bit of stage1 testing actually. I named it this way since the main directory in the source tree associated with these tests is "test/cases/". * add some documentation for the test manifest format.
2022-05-13 07:00:20 +00:00
const test_cases_step = b.step("test-cases", "Run the main compiler test cases");
test_cases_step.dependOn(&test_cases.step);
ci: drone: disable stage2 tests See #8545
2021-04-15 23:20:43 +00:00
if (!skip_stage2_tests) {
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(test_cases_step);
ci: drone: disable stage2 tests See #8545
2021-04-15 23:20:43 +00:00
}
self-hosted: first passing test * introduce std.atomic.Int * add src-self-hosted/test.zig which is tested by the main test suite - it fully utilizes the multithreaded async/await event loop so the tests should Go Fast * `stage2/bin/zig build-obj test.zig` is able to spit out an error if 2 exported functions collide * ability for `zig test` to accept `--object` and `--assembly` arguments * std.build: TestStep supports addLibPath and addObjectFile
2018-07-11 00:18:43 +00:00
ci: skip release-small tests to save time we keep hitting the limit on how long CI tests take to run.
2018-09-12 18:50:26 +00:00
var chosen_modes: [4]builtin.Mode = undefined;
var chosen_mode_index: usize = 0;
ci: drone disable debug test suite for aarch64 Temporary workaround for #8597 until upstream fix lands. - add `zig build -Dskip-debug` option - build a release-fast build.exe - disable test suite build modes { debug, release-small, release-safe } - enable passing test-* components - use parallel pipeline steps for tests
2021-04-24 20:39:26 +00:00
if (!skip_debug) {
chosen_modes[chosen_mode_index] = builtin.Mode.Debug;
chosen_mode_index += 1;
}
ci: skip release-small tests to save time we keep hitting the limit on how long CI tests take to run.
2018-09-12 18:50:26 +00:00
if (!skip_release_safe) {
chosen_modes[chosen_mode_index] = builtin.Mode.ReleaseSafe;
chosen_mode_index += 1;
}
if (!skip_release_fast) {
chosen_modes[chosen_mode_index] = builtin.Mode.ReleaseFast;
chosen_mode_index += 1;
}
if (!skip_release_small) {
chosen_modes[chosen_mode_index] = builtin.Mode.ReleaseSmall;
chosen_mode_index += 1;
}
const modes = chosen_modes[0..chosen_mode_index];
std.io: introduce buffered I/O and change API I started working on #465 and made some corresponding std.io API changes. New structs: * std.io.FileInStream * std.io.FileOutStream * std.io.BufferedOutStream * std.io.BufferedInStream Removed: * std.io.File.in_stream * std.io.File.out_stream Now instead of &file.out_stream or &file.in_stream to get access to the stream API for a file, you get it like this: var file_in_stream = io.FileInStream.init(&file); const in_stream = &file_in_stream.stream; var file_out_stream = io.FileOutStream.init(&file); const out_stream = &file_out_stream.stream; This is evidence that we might not need any OOP features - See #130.
2017-11-07 08:22:27 +00:00
add builder.addFmt API and use it to test stage1 zig fmt closes #1968
2019-02-26 23:10:40 +00:00
// run stage1 `zig fmt` on this build.zig file just to make sure it works
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(&fmt_build_zig.step);
add builder.addFmt API and use it to test stage1 zig fmt closes #1968
2019-02-26 23:10:40 +00:00
const fmt_step = b.step("test-fmt", "Run zig fmt against build.zig to make sure it works");
fmt_step.dependOn(&fmt_build_zig.step);
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(tests.addPkgTests(
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
b,
test_filter,
Merge remote-tracking branch 'origin/master' into stage2-whole-file-astgen Conflicts: * build.zig * src/Compilation.zig * src/codegen/spirv/spec.zig * src/link/SpirV.zig * test/stage2/darwin.zig - this one might be problematic; start.zig looks for `main` in the root source file, not `_main`. Not sure why there is an underscore there in master branch.
2021-05-16 04:44:38 +00:00
"test/behavior.zig",
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
"behavior",
"Run the behavior tests",
modes,
CI: skip single-threaded tests on Drone sure would be nice if they would just give us another hour of CI run time.
2022-06-01 21:05:58 +00:00
skip_single_threaded,
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
skip_non_native,
skip_libc,
CI: add non-LLVM backends to the test matrix We can't yet run the behavior tests with stage3, but at least we can run them with stage2, and we can use the proper test matrix. This commit also adds use_llvm and ofmt to the zig build system.
2022-04-22 03:28:36 +00:00
skip_stage1,
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
skip_stage2_tests,
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
));
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(tests.addPkgTests(
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
b,
test_filter,
flatten lib/std/special and improve "pkg inside another" logic stage2: change logic for detecting whether the main package is inside the std package. Previously it relied on realpath() which is not portable. This uses resolve() which is how imports already work. * stage2: fix cleanup bug when creating Module * flatten lib/std/special/* to lib/* - this was motivated by making main_pkg_is_inside_std false for compiler_rt & friends. * rename "mini libc" to "universal libc"
2022-05-07 02:22:40 +00:00
"lib/compiler_rt.zig",
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
"compiler-rt",
"Run the compiler_rt tests",
modes,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
true, // skip_single_threaded
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
skip_non_native,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
true, // skip_libc
CI: add non-LLVM backends to the test matrix We can't yet run the behavior tests with stage3, but at least we can run them with stage2, and we can use the proper test matrix. This commit also adds use_llvm and ofmt to the zig build system.
2022-04-22 03:28:36 +00:00
skip_stage1,
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
skip_stage2_tests or true, // TODO get these all passing
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
));
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(tests.addPkgTests(
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
b,
test_filter,
flatten lib/std/special and improve "pkg inside another" logic stage2: change logic for detecting whether the main package is inside the std package. Previously it relied on realpath() which is not portable. This uses resolve() which is how imports already work. * stage2: fix cleanup bug when creating Module * flatten lib/std/special/* to lib/* - this was motivated by making main_pkg_is_inside_std false for compiler_rt & friends. * rename "mini libc" to "universal libc"
2022-05-07 02:22:40 +00:00
"lib/c.zig",
"universal-libc",
"Run the universal libc tests",
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
modes,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
true, // skip_single_threaded
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
skip_non_native,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
true, // skip_libc
CI: add non-LLVM backends to the test matrix We can't yet run the behavior tests with stage3, but at least we can run them with stage2, and we can use the proper test matrix. This commit also adds use_llvm and ofmt to the zig build system.
2022-04-22 03:28:36 +00:00
skip_stage1,
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
skip_stage2_tests or true, // TODO get these all passing
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
));
Azure CI: Test std.* and the rest separately On CI, we have been running into OOM issues when running the test suite on Windows for quite some time. Unfortunately, we are very close to having the same issues on Linux as well. Some additional comptime work immediately makes these builds fail as well. Add a new `test-toolchain` step, that tests everything except `std.*` and documentation. On CI, call `test-toolchain`, `test-std` and `docs` separately instead of the `test` big hammer that emcompasses all of them. Change the special case we made for Windows to the same code as other platforms. This is a stopgap measure that stage2 will eventually make useless. Until then, it gives us some headroom. Change `linux_script` by the way to only output the log of failing steps. This shrinks the Linux CI log from a bazilion lines down to something more humanely manageable.
2021-04-30 21:41:28 +00:00
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(tests.addCompareOutputTests(b, test_filter, modes));
test_step.dependOn(tests.addStandaloneTests(
wasm: Enable C-ABI tests for self-hosted compiler
2022-07-20 19:51:18 +00:00
b,
test_filter,
modes,
skip_non_native,
enable_macos_sdk,
target,
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
skip_stage2_tests,
wasm: Enable C-ABI tests for self-hosted compiler
2022-07-20 19:51:18 +00:00
b.enable_darling,
b.enable_qemu,
b.enable_rosetta,
b.enable_wasmtime,
b.enable_wine,
test-link: add -Denable-symlinks-windows to opt-in to using symlinks Adds a way for standalone tests to declare they need symlinks, and these tests won't be run on windows unless -Denable-symlinks-windows is set
2022-11-26 19:23:32 +00:00
enable_symlinks_windows,
wasm: Enable C-ABI tests for self-hosted compiler
2022-07-20 19:51:18 +00:00
));
build.zig: separate C ABI tests from standalone tests
2022-10-21 20:01:49 +00:00
test_step.dependOn(tests.addCAbiTests(b, skip_non_native));
test-link: add -Denable-symlinks-windows to opt-in to using symlinks Adds a way for standalone tests to declare they need symlinks, and these tests won't be run on windows unless -Denable-symlinks-windows is set
2022-11-26 19:23:32 +00:00
test_step.dependOn(tests.addLinkTests(b, test_filter, modes, enable_macos_sdk, skip_stage2_tests, enable_symlinks_windows));
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(tests.addStackTraceTests(b, test_filter, modes));
test_step.dependOn(tests.addCliTests(b, test_filter, modes));
test_step.dependOn(tests.addAssembleAndLinkTests(b, test_filter, modes));
test_step.dependOn(tests.addTranslateCTests(b, test_filter));
ci: aarch64-linux: disable run-translated-c tests See #8537
2021-04-15 06:10:51 +00:00
if (!skip_run_translated_c) {
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(tests.addRunTranslatedCTests(b, test_filter, target));
ci: aarch64-linux: disable run-translated-c tests See #8537
2021-04-15 06:10:51 +00:00
}
"generate .h files" feature is no longer supported in stage1
2020-03-20 22:33:36 +00:00
// tests for this feature are disabled until we have the self-hosted compiler available
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
// test_step.dependOn(tests.addGenHTests(b, test_filter));
Azure CI: Test std.* and the rest separately On CI, we have been running into OOM issues when running the test suite on Windows for quite some time. Unfortunately, we are very close to having the same issues on Linux as well. Some additional comptime work immediately makes these builds fail as well. Add a new `test-toolchain` step, that tests everything except `std.*` and documentation. On CI, call `test-toolchain`, `test-std` and `docs` separately instead of the `test` big hammer that emcompasses all of them. Change the special case we made for Windows to the same code as other platforms. This is a stopgap measure that stage2 will eventually make useless. Until then, it gives us some headroom. Change `linux_script` by the way to only output the log of failing steps. This shrinks the Linux CI log from a bazilion lines down to something more humanely manageable.
2021-04-30 21:41:28 +00:00
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
test_step.dependOn(tests.addPkgTests(
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
b,
test_filter,
"lib/std/std.zig",
"std",
"Run the standard library tests",
modes,
CI: skip single-threaded tests on Drone sure would be nice if they would just give us another hour of CI run time.
2022-06-01 21:05:58 +00:00
skip_single_threaded,
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
skip_non_native,
skip_libc,
CI: add non-LLVM backends to the test matrix We can't yet run the behavior tests with stage3, but at least we can run them with stage2, and we can use the proper test matrix. This commit also adds use_llvm and ofmt to the zig build system.
2022-04-22 03:28:36 +00:00
skip_stage1,
build: remove the option to omit stage2
2022-08-08 01:17:31 +00:00
true, // TODO get these all passing
build: hook up -Dskip-stage2-tests and remove test-toolchain
2022-08-18 05:17:19 +00:00
));
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
try addWasiUpdateStep(b, version);
}
fn addWasiUpdateStep(b: *Builder, version: [:0]const u8) !void {
const semver = try std.SemanticVersion.parse(version);
var target: std.zig.CrossTarget = .{
.cpu_arch = .wasm32,
.os_tag = .wasi,
};
target.cpu_features_add.addFeature(@enumToInt(std.Target.wasm.Feature.bulk_memory));
const exe = addCompilerStep(b);
exe.setBuildMode(.ReleaseSmall);
exe.setTarget(target);
const exe_options = b.addOptions();
exe.addOptions("build_options", exe_options);
exe_options.addOption(u32, "mem_leak_frames", 0);
exe_options.addOption(bool, "have_llvm", false);
exe_options.addOption(bool, "force_gpa", false);
exe_options.addOption(bool, "only_c", true);
exe_options.addOption([:0]const u8, "version", version);
exe_options.addOption(std.SemanticVersion, "semver", semver);
exe_options.addOption(bool, "enable_logging", false);
exe_options.addOption(bool, "enable_link_snapshots", false);
exe_options.addOption(bool, "enable_tracy", false);
exe_options.addOption(bool, "enable_tracy_callstack", false);
exe_options.addOption(bool, "enable_tracy_allocation", false);
exe_options.addOption(bool, "value_tracing", false);
const run_opt = b.addSystemCommand(&.{ "wasm-opt", "-Oz", "--enable-bulk-memory" });
run_opt.addArtifactArg(exe);
run_opt.addArg("-o");
run_opt.addFileSourceArg(.{ .path = "stage1/zig1.wasm" });
remove the zstd mechanism from the build process
2022-12-09 23:33:32 +00:00
const update_zig1_step = b.step("update-zig1", "Update stage1/zig1.wasm");
update_zig1_step.dependOn(&run_opt.step);
build: remove -Dwasi-bootstrap; add update-zig1 step Now it is a single command tdo update zig1.wasm.zst.
2022-12-01 23:34:15 +00:00
}
fn addCompilerStep(b: *Builder) *std.build.LibExeObjStep {
const exe = b.addExecutable("zig", "src/main.zig");
exe.stack_size = stack_size;
return exe;
convert compare-output tests to use zig build system
2017-04-19 05:13:15 +00:00
}
self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
const exe_cflags = [_][]const u8{
"-std=c++14",
"-D__STDC_CONSTANT_MACROS",
"-D__STDC_FORMAT_MACROS",
"-D__STDC_LIMIT_MACROS",
"-D_GNU_SOURCE",
"-fvisibility-inlines-hidden",
"-fno-exceptions",
"-fno-rtti",
"-Werror=type-limits",
"-Wno-missing-braces",
"-Wno-comment",
};
fn addCmakeCfgOptionsToExe(
b: *Builder,
cfg: CMakeConfig,
exe: *std.build.LibExeObjStep,
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
use_zig_libcxx: bool,
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
) !void {
exe.addObjectFile(fs.path.join(b.allocator, &[_][]const u8{
cfg.cmake_binary_dir,
"zigcpp",
build: obtain zigcpp library prefix/suffix from cmake
2022-12-07 08:44:15 +00:00
b.fmt("{s}{s}{s}", .{
cfg.cmake_static_library_prefix,
"zigcpp",
cfg.cmake_static_library_suffix,
}),
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
}) catch unreachable);
assert(cfg.lld_include_dir.len != 0);
Normalize some build function names An attempt to normalize some of the function names in build.zig. Normalize add*Dir to add*Path. Also use "Library" instead of the "Lib" abbreviation. The PR does not remove the old names, only adds the new normalized ones to faciliate a transition period.
2022-01-24 18:15:32 +00:00
exe.addIncludePath(cfg.lld_include_dir);
build.zig: Forward LLVM lib/include dirs from CMake Previously, you might obtain `-lLLVM-15` from the CMake configuration, but we might not be able to locate the library if it's not in your system library path.
2022-10-12 22:11:46 +00:00
exe.addIncludePath(cfg.llvm_include_dir);
exe.addLibraryPath(cfg.llvm_lib_dir);
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
addCMakeLibraryList(exe, cfg.clang_libraries);
addCMakeLibraryList(exe, cfg.lld_libraries);
addCMakeLibraryList(exe, cfg.llvm_libraries);
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
if (use_zig_libcxx) {
exe.linkLibCpp();
} else {
const need_cpp_includes = true;
Dynamically link libc++, if integrating with system LLVM This ensures that the zigcpp clang driver and LLVM are using the same copy of libc++. See prior commit for more details.
2022-07-12 01:47:54 +00:00
const lib_suffix = switch (cfg.llvm_linkage) {
.static => exe.target.staticLibSuffix()[1..],
.dynamic => exe.target.dynamicLibSuffix()[1..],
};
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
// System -lc++ must be used because in this code path we are attempting to link
// against system-provided LLVM, Clang, LLD.
build stage3: add more BSD support - add netbsd - add dragonfly - fixup freebsd
2023-01-03 00:18:33 +00:00
switch (exe.target.getOsTag()) {
.linux => {
// First we try to link against gcc libstdc++. If that doesn't work, we fall
// back to -lc++ and cross our fingers.
addCxxKnownPath(b, cfg, exe, b.fmt("libstdc++.{s}", .{lib_suffix}), "", need_cpp_includes) catch |err| switch (err) {
error.RequiredLibraryNotFound => {
exe.linkSystemLibrary("c++");
},
else => |e| return e,
};
exe.linkSystemLibrary("unwind");
},
.ios, .macos, .watchos, .tvos => {
exe.linkSystemLibrary("c++");
},
.freebsd => {
try addCxxKnownPath(b, cfg, exe, b.fmt("libc++.{s}", .{lib_suffix}), null, need_cpp_includes);
try addCxxKnownPath(b, cfg, exe, b.fmt("libgcc_eh.{s}", .{lib_suffix}), null, need_cpp_includes);
},
.openbsd => {
try addCxxKnownPath(b, cfg, exe, b.fmt("libc++.{s}", .{lib_suffix}), null, need_cpp_includes);
try addCxxKnownPath(b, cfg, exe, b.fmt("libc++abi.{s}", .{lib_suffix}), null, need_cpp_includes);
},
.netbsd => {
try addCxxKnownPath(b, cfg, exe, b.fmt("libstdc++.{s}", .{lib_suffix}), null, need_cpp_includes);
try addCxxKnownPath(b, cfg, exe, b.fmt("libgcc_eh.{s}", .{lib_suffix}), null, need_cpp_includes);
},
.dragonfly => {
try addCxxKnownPath(b, cfg, exe, b.fmt("libstdc++.{s}", .{lib_suffix}), null, need_cpp_includes);
try addCxxKnownPath(b, cfg, exe, b.fmt("libgcc_eh.{s}", .{lib_suffix}), null, need_cpp_includes);
},
else => {},
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
}
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
}
if (cfg.dia_guids_lib.len != 0) {
exe.addObjectFile(cfg.dia_guids_lib);
}
}
CLI: resolve system libs into static libraries using the provided -L directories before checking if we need to integrate with system library paths. This prevents false positive of invoking system cc to find native paths when in fact all dependencies are satisfied by -L (or --search-prefix to zig build).
2022-02-17 23:55:12 +00:00
fn addStaticLlvmOptionsToExe(exe: *std.build.LibExeObjStep) !void {
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
// Adds the Zig C++ sources which both stage1 and stage2 need.
//
// We need this because otherwise zig_clang_cc1_main.cpp ends up pulling
// in a dependency on llvm::cfg::Update<llvm::BasicBlock*>::dump() which is
// unavailable when LLVM is compiled in Release mode.
const zig_cpp_cflags = exe_cflags ++ [_][]const u8{"-DNDEBUG=1"};
exe.addCSourceFiles(&zig_cpp_sources, &zig_cpp_cflags);
for (clang_libs) |lib_name| {
exe.linkSystemLibrary(lib_name);
}
for (lld_libs) |lib_name| {
exe.linkSystemLibrary(lib_name);
}
for (llvm_libs) |lib_name| {
exe.linkSystemLibrary(lib_name);
}
Add zlib to needed libraries
2021-10-02 19:58:16 +00:00
exe.linkSystemLibrary("z");
build: include -lzstd in the linker line when building Zig
2022-10-25 21:55:58 +00:00
exe.linkSystemLibrary("zstd");
Add zlib to needed libraries
2021-10-02 19:58:16 +00:00
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
// This means we rely on clang-or-zig-built LLVM, Clang, LLD libraries.
exe.linkSystemLibrary("c++");
}
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
fn addCxxKnownPath(
b: *Builder,
ctx: CMakeConfig,
exe: *std.build.LibExeObjStep,
objname: []const u8,
errtxt: ?[]const u8,
need_cpp_includes: bool,
) !void {
Avoid depending on child process execution when not supported by host OS In accordance with the requesting issue (#10750): - `zig test` skips any tests that it cannot spawn, returning success - `zig run` and `zig build` exit with failure, reporting the command the cannot be run - `zig clang`, `zig ar`, etc. already punt directly to the appropriate clang/lld main(), even before this change - Native `libc` Detection is not supported Additionally, `exec()` and related Builder functions error at run-time, reporting the command that cannot be run
2022-02-03 22:27:01 +00:00
if (!std.process.can_spawn)
return error.RequiredLibraryNotFound;
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
const path_padded = try b.exec(&[_][]const u8{
ctx.cxx_compiler,
tests: Use {s} instead of {} when formatting strings
2020-11-26 12:28:38 +00:00
b.fmt("-print-file-name={s}", .{objname}),
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
});
Value: hash lazy_align
2022-03-27 18:05:42 +00:00
var tokenizer = mem.tokenize(u8, path_padded, "\r\n");
const path_unpadded = tokenizer.next().?;
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
if (mem.eql(u8, path_unpadded, objname)) {
if (errtxt) |msg| {
std lib API deprecations for the upcoming 0.9.0 release See #3811
2021-11-30 07:13:07 +00:00
std.debug.print("{s}", .{msg});
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
} else {
std lib API deprecations for the upcoming 0.9.0 release See #3811
2021-11-30 07:13:07 +00:00
std.debug.print("Unable to determine path to {s}\n", .{objname});
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
}
return error.RequiredLibraryNotFound;
}
exe.addObjectFile(path_unpadded);
// TODO a way to integrate with system c++ include files here
build: update Tracy integration * Update for v0.9 * Enable the memory and callstack integrations by default
2022-10-27 01:17:49 +00:00
// c++ -E -Wp,-v -xc++ /dev/null
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
if (need_cpp_includes) {
// I used these temporarily for testing something but we obviously need a
// more general purpose solution here.
build: update Tracy integration * Update for v0.9 * Enable the memory and callstack integrations by default
2022-10-27 01:17:49 +00:00
//exe.addIncludePath("/nix/store/2lr0fc0ak8rwj0k8n3shcyz1hz63wzma-gcc-11.3.0/include/c++/11.3.0");
//exe.addIncludePath("/nix/store/2lr0fc0ak8rwj0k8n3shcyz1hz63wzma-gcc-11.3.0/include/c++/11.3.0/x86_64-unknown-linux-gnu");
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
}
}
fn addCMakeLibraryList(exe: *std.build.LibExeObjStep, list: []const u8) void {
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 09:01:47 +00:00
var it = mem.tokenize(u8, list, ";");
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
while (it.next()) |lib| {
if (mem.startsWith(u8, lib, "-l")) {
exe.linkSystemLibrary(lib["-l".len..]);
} else {
exe.addObjectFile(lib);
}
}
}
const CMakeConfig = struct {
CMake: Add ZIG_LLVM_LINK_MODE to config.h This is currently unused, but it will be needed soon so that we can avoid linking static libc++ if LLVM/Clang is configured as a shared library.
2022-07-23 16:02:51 +00:00
llvm_linkage: std.build.LibExeObjStep.Linkage,
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
cmake_binary_dir: []const u8,
cmake_prefix_path: []const u8,
build: obtain zigcpp library prefix/suffix from cmake
2022-12-07 08:44:15 +00:00
cmake_static_library_prefix: []const u8,
cmake_static_library_suffix: []const u8,
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
cxx_compiler: []const u8,
lld_include_dir: []const u8,
lld_libraries: []const u8,
clang_libraries: []const u8,
build.zig: Forward LLVM lib/include dirs from CMake Previously, you might obtain `-lLLVM-15` from the CMake configuration, but we might not be able to locate the library if it's not in your system library path.
2022-10-12 22:11:46 +00:00
llvm_lib_dir: []const u8,
llvm_include_dir: []const u8,
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
llvm_libraries: []const u8,
dia_guids_lib: []const u8,
};
const max_config_h_bytes = 1 * 1024 * 1024;
build.zig: Emit warning if "config.h" cannot be found We now warn the user if config.h could not be located. This also updates the search to stop early upon encountering a `.git` directory, so that we avoid recursing outside of the zig source if possible.
2022-07-16 00:25:38 +00:00
fn findConfigH(b: *Builder, config_h_path_option: ?[]const u8) ?[]const u8 {
if (config_h_path_option) |path| {
var config_h_or_err = fs.cwd().openFile(path, .{});
if (config_h_or_err) |*file| {
file.close();
return path;
} else |_| {
std.log.err("Could not open provided config.h: \"{s}\"", .{path});
std.os.exit(1);
}
}
var check_dir = fs.path.dirname(b.zig_exe).?;
while (true) {
var dir = fs.cwd().openDir(check_dir, .{}) catch unreachable;
defer dir.close();
// Check if config.h is present in dir
var config_h_or_err = dir.openFile("config.h", .{});
if (config_h_or_err) |*file| {
file.close();
return fs.path.join(
b.allocator,
&[_][]const u8{ check_dir, "config.h" },
) catch unreachable;
} else |e| switch (e) {
error.FileNotFound => {},
else => unreachable,
}
// Check if we reached the source root by looking for .git, and bail if so
var git_dir_or_err = dir.openDir(".git", .{});
if (git_dir_or_err) |*git_dir| {
git_dir.close();
return null;
} else |_| {}
// Otherwise, continue search in the parent directory
const new_check_dir = fs.path.dirname(check_dir);
if (new_check_dir == null or mem.eql(u8, new_check_dir.?, check_dir)) {
return null;
}
check_dir = new_check_dir.?;
} else unreachable; // TODO should not need `else unreachable`.
}
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
build.zig: Emit warning if "config.h" cannot be found We now warn the user if config.h could not be located. This also updates the search to stop early upon encountering a `.git` directory, so that we avoid recursing outside of the zig source if possible.
2022-07-16 00:25:38 +00:00
fn parseConfigH(b: *Builder, config_h_text: []const u8) ?CMakeConfig {
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
var ctx: CMakeConfig = .{
CMake: Add ZIG_LLVM_LINK_MODE to config.h This is currently unused, but it will be needed soon so that we can avoid linking static libc++ if LLVM/Clang is configured as a shared library.
2022-07-23 16:02:51 +00:00
.llvm_linkage = undefined,
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
.cmake_binary_dir = undefined,
.cmake_prefix_path = undefined,
build: obtain zigcpp library prefix/suffix from cmake
2022-12-07 08:44:15 +00:00
.cmake_static_library_prefix = undefined,
.cmake_static_library_suffix = undefined,
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
.cxx_compiler = undefined,
.lld_include_dir = undefined,
.lld_libraries = undefined,
.clang_libraries = undefined,
build.zig: Forward LLVM lib/include dirs from CMake Previously, you might obtain `-lLLVM-15` from the CMake configuration, but we might not be able to locate the library if it's not in your system library path.
2022-10-12 22:11:46 +00:00
.llvm_lib_dir = undefined,
.llvm_include_dir = undefined,
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
.llvm_libraries = undefined,
.dia_guids_lib = undefined,
};
const mappings = [_]struct { prefix: []const u8, field: []const u8 }{
.{
.prefix = "#define ZIG_CMAKE_BINARY_DIR ",
.field = "cmake_binary_dir",
},
.{
.prefix = "#define ZIG_CMAKE_PREFIX_PATH ",
.field = "cmake_prefix_path",
},
build: obtain zigcpp library prefix/suffix from cmake
2022-12-07 08:44:15 +00:00
.{
.prefix = "#define ZIG_CMAKE_STATIC_LIBRARY_PREFIX ",
.field = "cmake_static_library_prefix",
},
.{
.prefix = "#define ZIG_CMAKE_STATIC_LIBRARY_SUFFIX ",
.field = "cmake_static_library_suffix",
},
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
.{
.prefix = "#define ZIG_CXX_COMPILER ",
.field = "cxx_compiler",
},
.{
.prefix = "#define ZIG_LLD_INCLUDE_PATH ",
.field = "lld_include_dir",
},
.{
.prefix = "#define ZIG_LLD_LIBRARIES ",
.field = "lld_libraries",
},
.{
.prefix = "#define ZIG_CLANG_LIBRARIES ",
.field = "clang_libraries",
},
.{
.prefix = "#define ZIG_LLVM_LIBRARIES ",
.field = "llvm_libraries",
},
.{
.prefix = "#define ZIG_DIA_GUIDS_LIB ",
.field = "dia_guids_lib",
},
build.zig: Forward LLVM lib/include dirs from CMake Previously, you might obtain `-lLLVM-15` from the CMake configuration, but we might not be able to locate the library if it's not in your system library path.
2022-10-12 22:11:46 +00:00
.{
.prefix = "#define ZIG_LLVM_INCLUDE_PATH ",
.field = "llvm_include_dir",
},
.{
.prefix = "#define ZIG_LLVM_LIB_PATH ",
.field = "llvm_lib_dir",
},
CMake: Add ZIG_LLVM_LINK_MODE to config.h This is currently unused, but it will be needed soon so that we can avoid linking static libc++ if LLVM/Clang is configured as a shared library.
2022-07-23 16:02:51 +00:00
// .prefix = ZIG_LLVM_LINK_MODE parsed manually below
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
};
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 09:01:47 +00:00
var lines_it = mem.tokenize(u8, config_h_text, "\r\n");
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
while (lines_it.next()) |line| {
inline for (mappings) |mapping| {
if (mem.startsWith(u8, line, mapping.prefix)) {
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 09:01:47 +00:00
var it = mem.split(u8, line, "\"");
std.mem: add `first` method to `SplitIterator` and `SplitBackwardsIterator`
2022-07-25 19:04:30 +00:00
_ = it.first(); // skip the stuff before the quote
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
const quoted = it.next().?; // the stuff inside the quote
@field(ctx, mapping.field) = toNativePathSep(b, quoted);
}
}
CMake: Add ZIG_LLVM_LINK_MODE to config.h This is currently unused, but it will be needed soon so that we can avoid linking static libc++ if LLVM/Clang is configured as a shared library.
2022-07-23 16:02:51 +00:00
if (mem.startsWith(u8, line, "#define ZIG_LLVM_LINK_MODE ")) {
var it = mem.split(u8, line, "\"");
_ = it.next().?; // skip the stuff before the quote
const quoted = it.next().?; // the stuff inside the quote
ctx.llvm_linkage = if (mem.eql(u8, quoted, "shared")) .dynamic else .static;
}
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
}
return ctx;
}
fn toNativePathSep(b: *Builder, s: []const u8) []u8 {
std lib API deprecations for the upcoming 0.9.0 release See #3811
2021-11-30 07:13:07 +00:00
const duplicated = b.allocator.dupe(u8, s) catch unreachable;
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
for (duplicated) |*byte| switch (byte.*) {
'/' => byte.* = fs.path.sep,
else => {},
};
return duplicated;
}
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
const softfloat_sources = [_][]const u8{
"deps/SoftFloat-3e/source/8086/f128M_isSignalingNaN.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/8086/extF80M_isSignalingNaN.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/8086/s_commonNaNToF128M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/8086/s_commonNaNToExtF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/8086/s_commonNaNToF16UI.c",
"deps/SoftFloat-3e/source/8086/s_commonNaNToF32UI.c",
"deps/SoftFloat-3e/source/8086/s_commonNaNToF64UI.c",
"deps/SoftFloat-3e/source/8086/s_f128MToCommonNaN.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/8086/s_extF80MToCommonNaN.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/8086/s_f16UIToCommonNaN.c",
"deps/SoftFloat-3e/source/8086/s_f32UIToCommonNaN.c",
"deps/SoftFloat-3e/source/8086/s_f64UIToCommonNaN.c",
"deps/SoftFloat-3e/source/8086/s_propagateNaNF128M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/8086/s_propagateNaNExtF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/8086/s_propagateNaNF16UI.c",
"deps/SoftFloat-3e/source/8086/softfloat_raiseFlags.c",
"deps/SoftFloat-3e/source/f128M_add.c",
"deps/SoftFloat-3e/source/f128M_div.c",
"deps/SoftFloat-3e/source/f128M_eq.c",
"deps/SoftFloat-3e/source/f128M_eq_signaling.c",
"deps/SoftFloat-3e/source/f128M_le.c",
"deps/SoftFloat-3e/source/f128M_le_quiet.c",
"deps/SoftFloat-3e/source/f128M_lt.c",
"deps/SoftFloat-3e/source/f128M_lt_quiet.c",
"deps/SoftFloat-3e/source/f128M_mul.c",
"deps/SoftFloat-3e/source/f128M_mulAdd.c",
"deps/SoftFloat-3e/source/f128M_rem.c",
"deps/SoftFloat-3e/source/f128M_roundToInt.c",
"deps/SoftFloat-3e/source/f128M_sqrt.c",
"deps/SoftFloat-3e/source/f128M_sub.c",
"deps/SoftFloat-3e/source/f128M_to_f16.c",
"deps/SoftFloat-3e/source/f128M_to_f32.c",
"deps/SoftFloat-3e/source/f128M_to_f64.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/f128M_to_extF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/f128M_to_i32.c",
"deps/SoftFloat-3e/source/f128M_to_i32_r_minMag.c",
"deps/SoftFloat-3e/source/f128M_to_i64.c",
"deps/SoftFloat-3e/source/f128M_to_i64_r_minMag.c",
"deps/SoftFloat-3e/source/f128M_to_ui32.c",
"deps/SoftFloat-3e/source/f128M_to_ui32_r_minMag.c",
"deps/SoftFloat-3e/source/f128M_to_ui64.c",
"deps/SoftFloat-3e/source/f128M_to_ui64_r_minMag.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/extF80M_add.c",
"deps/SoftFloat-3e/source/extF80M_div.c",
"deps/SoftFloat-3e/source/extF80M_eq.c",
"deps/SoftFloat-3e/source/extF80M_le.c",
"deps/SoftFloat-3e/source/extF80M_lt.c",
"deps/SoftFloat-3e/source/extF80M_mul.c",
"deps/SoftFloat-3e/source/extF80M_rem.c",
"deps/SoftFloat-3e/source/extF80M_roundToInt.c",
"deps/SoftFloat-3e/source/extF80M_sqrt.c",
"deps/SoftFloat-3e/source/extF80M_sub.c",
"deps/SoftFloat-3e/source/extF80M_to_f16.c",
"deps/SoftFloat-3e/source/extF80M_to_f32.c",
"deps/SoftFloat-3e/source/extF80M_to_f64.c",
"deps/SoftFloat-3e/source/extF80M_to_f128M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/f16_add.c",
"deps/SoftFloat-3e/source/f16_div.c",
"deps/SoftFloat-3e/source/f16_eq.c",
"deps/SoftFloat-3e/source/f16_isSignalingNaN.c",
"deps/SoftFloat-3e/source/f16_lt.c",
"deps/SoftFloat-3e/source/f16_mul.c",
"deps/SoftFloat-3e/source/f16_mulAdd.c",
"deps/SoftFloat-3e/source/f16_rem.c",
"deps/SoftFloat-3e/source/f16_roundToInt.c",
"deps/SoftFloat-3e/source/f16_sqrt.c",
"deps/SoftFloat-3e/source/f16_sub.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/f16_to_extF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/f16_to_f128M.c",
"deps/SoftFloat-3e/source/f16_to_f64.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/f32_to_extF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/f32_to_f128M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/f64_to_extF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/f64_to_f128M.c",
"deps/SoftFloat-3e/source/f64_to_f16.c",
"deps/SoftFloat-3e/source/i32_to_f128M.c",
"deps/SoftFloat-3e/source/s_add256M.c",
"deps/SoftFloat-3e/source/s_addCarryM.c",
"deps/SoftFloat-3e/source/s_addComplCarryM.c",
"deps/SoftFloat-3e/source/s_addF128M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/s_addExtF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/s_addM.c",
"deps/SoftFloat-3e/source/s_addMagsF16.c",
"deps/SoftFloat-3e/source/s_addMagsF32.c",
"deps/SoftFloat-3e/source/s_addMagsF64.c",
"deps/SoftFloat-3e/source/s_approxRecip32_1.c",
"deps/SoftFloat-3e/source/s_approxRecipSqrt32_1.c",
"deps/SoftFloat-3e/source/s_approxRecipSqrt_1Ks.c",
"deps/SoftFloat-3e/source/s_approxRecip_1Ks.c",
"deps/SoftFloat-3e/source/s_compare128M.c",
"deps/SoftFloat-3e/source/s_compare96M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/s_compareNonnormExtF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/s_countLeadingZeros16.c",
"deps/SoftFloat-3e/source/s_countLeadingZeros32.c",
"deps/SoftFloat-3e/source/s_countLeadingZeros64.c",
"deps/SoftFloat-3e/source/s_countLeadingZeros8.c",
"deps/SoftFloat-3e/source/s_eq128.c",
"deps/SoftFloat-3e/source/s_invalidF128M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/s_invalidExtF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/s_isNaNF128M.c",
"deps/SoftFloat-3e/source/s_le128.c",
"deps/SoftFloat-3e/source/s_lt128.c",
"deps/SoftFloat-3e/source/s_mul128MTo256M.c",
"deps/SoftFloat-3e/source/s_mul64To128M.c",
"deps/SoftFloat-3e/source/s_mulAddF128M.c",
"deps/SoftFloat-3e/source/s_mulAddF16.c",
"deps/SoftFloat-3e/source/s_mulAddF32.c",
"deps/SoftFloat-3e/source/s_mulAddF64.c",
"deps/SoftFloat-3e/source/s_negXM.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/s_normExtF80SigM.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/s_normRoundPackMToF128M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/s_normRoundPackMToExtF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/s_normRoundPackToF16.c",
"deps/SoftFloat-3e/source/s_normRoundPackToF32.c",
"deps/SoftFloat-3e/source/s_normRoundPackToF64.c",
"deps/SoftFloat-3e/source/s_normSubnormalF128SigM.c",
"deps/SoftFloat-3e/source/s_normSubnormalF16Sig.c",
"deps/SoftFloat-3e/source/s_normSubnormalF32Sig.c",
"deps/SoftFloat-3e/source/s_normSubnormalF64Sig.c",
"deps/SoftFloat-3e/source/s_remStepMBy32.c",
"deps/SoftFloat-3e/source/s_roundMToI64.c",
"deps/SoftFloat-3e/source/s_roundMToUI64.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/s_roundPackMToExtF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/s_roundPackMToF128M.c",
"deps/SoftFloat-3e/source/s_roundPackToF16.c",
"deps/SoftFloat-3e/source/s_roundPackToF32.c",
"deps/SoftFloat-3e/source/s_roundPackToF64.c",
"deps/SoftFloat-3e/source/s_roundToI32.c",
"deps/SoftFloat-3e/source/s_roundToI64.c",
"deps/SoftFloat-3e/source/s_roundToUI32.c",
"deps/SoftFloat-3e/source/s_roundToUI64.c",
"deps/SoftFloat-3e/source/s_shiftLeftM.c",
"deps/SoftFloat-3e/source/s_shiftNormSigF128M.c",
"deps/SoftFloat-3e/source/s_shiftRightJam256M.c",
"deps/SoftFloat-3e/source/s_shiftRightJam32.c",
"deps/SoftFloat-3e/source/s_shiftRightJam64.c",
"deps/SoftFloat-3e/source/s_shiftRightJamM.c",
"deps/SoftFloat-3e/source/s_shiftRightM.c",
"deps/SoftFloat-3e/source/s_shortShiftLeft64To96M.c",
"deps/SoftFloat-3e/source/s_shortShiftLeftM.c",
"deps/SoftFloat-3e/source/s_shortShiftRightExtendM.c",
"deps/SoftFloat-3e/source/s_shortShiftRightJam64.c",
"deps/SoftFloat-3e/source/s_shortShiftRightJamM.c",
"deps/SoftFloat-3e/source/s_shortShiftRightM.c",
"deps/SoftFloat-3e/source/s_sub1XM.c",
"deps/SoftFloat-3e/source/s_sub256M.c",
"deps/SoftFloat-3e/source/s_subM.c",
"deps/SoftFloat-3e/source/s_subMagsF16.c",
"deps/SoftFloat-3e/source/s_subMagsF32.c",
"deps/SoftFloat-3e/source/s_subMagsF64.c",
"deps/SoftFloat-3e/source/s_tryPropagateNaNF128M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/s_tryPropagateNaNExtF80M.c",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"deps/SoftFloat-3e/source/softfloat_state.c",
"deps/SoftFloat-3e/source/ui32_to_f128M.c",
"deps/SoftFloat-3e/source/ui64_to_f128M.c",
build.zig: bootstrap stage1 with zig0 Instead of assuming that the zig version used with `zig build` is appropriate for building the self-hosted compiler component, we follow the same path as the cmake build script and build zig0, using that to produce zig1.o, re-linking to produce stage1. This allows an arbitrarily old Zig version and corresponding build.zig script to build all future versions of Zig from source via the bootstrap compiler. In other words, it allows us to use `zig build` as an alternative to cmake when bootstrapping.
2022-02-16 20:50:47 +00:00
"deps/SoftFloat-3e/source/ui32_to_extF80M.c",
"deps/SoftFloat-3e/source/ui64_to_extF80M.c",
self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
};
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
const zig_cpp_sources = [_][]const u8{
// These are planned to stay even when we are self-hosted.
"src/zig_llvm.cpp",
"src/zig_clang.cpp",
Add zig_llvm-ar.cpp in build.zig This was added in 0afb5b2ec6de494efe0605b2270f6a01b95237af 8 days ago, but it seems it was only added in the cmake files and not build.zig
2021-06-06 00:33:16 +00:00
"src/zig_llvm-ar.cpp",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"src/zig_clang_driver.cpp",
"src/zig_clang_cc1_main.cpp",
"src/zig_clang_cc1as_main.cpp",
// https://github.com/ziglang/zig/issues/6363
"src/windows_sdk.cpp",
self-hosted: first passing test * introduce std.atomic.Int * add src-self-hosted/test.zig which is tested by the main test suite - it fully utilizes the multithreaded async/await event loop so the tests should Go Fast * `stage2/bin/zig build-obj test.zig` is able to spit out an error if 2 exported functions collide * ability for `zig test` to accept `--object` and `--assembly` arguments * std.build: TestStep supports addLibPath and addObjectFile
2018-07-11 00:18:43 +00:00
};
remove `zig BUILD_INFO` hack Rather than stuffing configuration information into the Zig binary, the build script reads it from config.h. This solves a problem for package maintainers and improves the use case of deterministic builds. closes #3758
2020-04-04 15:57:28 +00:00
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
const clang_libs = [_][]const u8{
"clangFrontendTool",
"clangCodeGen",
"clangFrontend",
"clangDriver",
"clangSerialization",
"clangSema",
"clangStaticAnalyzerFrontend",
"clangStaticAnalyzerCheckers",
"clangStaticAnalyzerCore",
"clangAnalysis",
"clangASTMatchers",
"clangAST",
"clangParse",
"clangSema",
"clangBasic",
"clangEdit",
"clangLex",
"clangARCMigrate",
"clangRewriteFrontend",
"clangRewrite",
"clangCrossTU",
"clangIndex",
"clangToolingCore",
build: add new clang libraries for LLVM 15 upgrade
2022-08-03 00:14:19 +00:00
"clangExtractAPI",
"clangSupport",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
};
const lld_libs = [_][]const u8{
"lldMinGW",
"lldELF",
"lldCOFF",
"lldWasm",
update build scripts to LLD and LLVM 14 libraries
2022-07-04 01:41:43 +00:00
"lldMachO",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"lldCommon",
};
// This list can be re-generated with `llvm-config --libfiles` and then
// reformatting using your favorite text editor. Note we do not execute
build.zig: omit LLVMTableGen from llvm libs
2021-04-15 17:58:53 +00:00
// `llvm-config` here because we are cross compiling. Also omit LLVMTableGen
// from these libs.
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
const llvm_libs = [_][]const u8{
"LLVMWindowsManifest",
update LLVM library list to LLVM 15
2022-08-02 23:57:32 +00:00
"LLVMWindowsDriver",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMXRay",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMLibDriver",
"LLVMDlltoolDriver",
"LLVMCoverage",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMLineEditor",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMXCoreDisassembler",
"LLVMXCoreCodeGen",
"LLVMXCoreDesc",
"LLVMXCoreInfo",
update build scripts to LLD and LLVM 14 libraries
2022-07-04 01:41:43 +00:00
"LLVMX86TargetMCA",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMX86Disassembler",
"LLVMX86AsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMX86CodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMX86Desc",
"LLVMX86Info",
"LLVMWebAssemblyDisassembler",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMWebAssemblyAsmParser",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMWebAssemblyCodeGen",
"LLVMWebAssemblyDesc",
build.zig: update list of LLVM libs companion commit to 0f35a1f37ade9cf25707c41711b352174f1e2789 fixes compiling with a dev kit.
2021-10-02 19:40:07 +00:00
"LLVMWebAssemblyUtils",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMWebAssemblyInfo",
update build scripts to LLD and LLVM 14 libraries
2022-07-04 01:41:43 +00:00
"LLVMVEDisassembler",
"LLVMVEAsmParser",
"LLVMVECodeGen",
"LLVMVEDesc",
"LLVMVEInfo",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMSystemZDisassembler",
"LLVMSystemZAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMSystemZCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMSystemZDesc",
"LLVMSystemZInfo",
"LLVMSparcDisassembler",
"LLVMSparcAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMSparcCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMSparcDesc",
"LLVMSparcInfo",
"LLVMRISCVDisassembler",
"LLVMRISCVAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMRISCVCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMRISCVDesc",
"LLVMRISCVInfo",
"LLVMPowerPCDisassembler",
"LLVMPowerPCAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMPowerPCCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMPowerPCDesc",
"LLVMPowerPCInfo",
"LLVMNVPTXCodeGen",
"LLVMNVPTXDesc",
"LLVMNVPTXInfo",
"LLVMMSP430Disassembler",
"LLVMMSP430AsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMMSP430CodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMMSP430Desc",
"LLVMMSP430Info",
"LLVMMipsDisassembler",
"LLVMMipsAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMMipsCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMMipsDesc",
"LLVMMipsInfo",
"LLVMLanaiDisassembler",
"LLVMLanaiCodeGen",
"LLVMLanaiAsmParser",
"LLVMLanaiDesc",
"LLVMLanaiInfo",
"LLVMHexagonDisassembler",
"LLVMHexagonCodeGen",
"LLVMHexagonAsmParser",
"LLVMHexagonDesc",
"LLVMHexagonInfo",
"LLVMBPFDisassembler",
"LLVMBPFAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMBPFCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMBPFDesc",
"LLVMBPFInfo",
"LLVMAVRDisassembler",
"LLVMAVRAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMAVRCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAVRDesc",
"LLVMAVRInfo",
"LLVMARMDisassembler",
"LLVMARMAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMARMCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMARMDesc",
"LLVMARMUtils",
"LLVMARMInfo",
update build scripts to LLD and LLVM 14 libraries
2022-07-04 01:41:43 +00:00
"LLVMAMDGPUTargetMCA",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAMDGPUDisassembler",
"LLVMAMDGPUAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMAMDGPUCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAMDGPUDesc",
"LLVMAMDGPUUtils",
"LLVMAMDGPUInfo",
"LLVMAArch64Disassembler",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMAArch64AsmParser",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAArch64CodeGen",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMAArch64Desc",
"LLVMAArch64Utils",
"LLVMAArch64Info",
"LLVMOrcJIT",
"LLVMMCJIT",
"LLVMJITLink",
"LLVMInterpreter",
"LLVMExecutionEngine",
"LLVMRuntimeDyld",
build.zig: update list of LLVM libs companion commit to 0f35a1f37ade9cf25707c41711b352174f1e2789 fixes compiling with a dev kit.
2021-10-02 19:40:07 +00:00
"LLVMOrcTargetProcess",
"LLVMOrcShared",
"LLVMDWP",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMDebugInfoGSYM",
"LLVMOption",
"LLVMObjectYAML",
update LLVM library list to LLVM 15
2022-08-02 23:57:32 +00:00
"LLVMObjCopy",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMMCA",
"LLVMMCDisassembler",
"LLVMLTO",
"LLVMPasses",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMCFGuard",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMCoroutines",
"LLVMObjCARCOpts",
"LLVMipo",
"LLVMVectorize",
"LLVMLinker",
"LLVMInstrumentation",
"LLVMFrontendOpenMP",
"LLVMFrontendOpenACC",
"LLVMExtensions",
"LLVMDWARFLinker",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMGlobalISel",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMMIRParser",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAsmPrinter",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMSelectionDAG",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMCodeGen",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMIRReader",
"LLVMAsmParser",
"LLVMInterfaceStub",
"LLVMFileCheck",
"LLVMFuzzMutate",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMTarget",
"LLVMScalarOpts",
"LLVMInstCombine",
"LLVMAggressiveInstCombine",
"LLVMTransformUtils",
"LLVMBitWriter",
"LLVMAnalysis",
"LLVMProfileData",
update LLVM library list to LLVM 15
2022-08-02 23:57:32 +00:00
"LLVMSymbolize",
"LLVMDebugInfoPDB",
"LLVMDebugInfoMSF",
update build scripts to LLD and LLVM 14 libraries
2022-07-04 01:41:43 +00:00
"LLVMDebugInfoDWARF",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMObject",
"LLVMTextAPI",
"LLVMMCParser",
"LLVMMC",
"LLVMDebugInfoCodeView",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMBitReader",
update LLVM library list to LLVM 15
2022-08-02 23:57:32 +00:00
"LLVMFuzzerCLI",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMCore",
"LLVMRemarks",
"LLVMBitstreamReader",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMBinaryFormat",
"LLVMSupport",
"LLVMDemangle",
};
Reference in New Issue Copy Permalink