jimzah/zig
1
0
Fork 0
mirror of https://github.com/ziglang/zig.git synced 2024-11-27 07:32:44 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
b6930825b0
zig/build.zig

1151 lines
44 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-13 00:44:51 +01: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 06:13:15 +01: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 18:17:34 +01: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 08:06:20 +01: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 04:23:00 +01:00
const assert = std.debug.assert;
convert compare-output tests to use zig build system
2017-04-19 06:13:15 +01:00
start the 0.10.0 release cycle
2021-12-20 20:13:48 +00:00
const zig_version = std.builtin.Version{ .major = 0, .minor = 10, .patch = 0 };
stage2: implement zig version
2020-08-15 22:17:40 +01: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 15:56:59 +01:00
pub fn build(b: *Builder) !void {
zig build: search upwards for build.zig file closes #2587
2019-07-04 22:43:56 +01:00
b.setPreferredReleaseMode(.ReleaseFast);
self hosted zig: print usage
2017-10-21 22:31:06 +01:00
const mode = b.standardReleaseOptions();
stage2: remove some dead code, fix build on aarch64
2020-07-21 19:18:51 +01:00
const target = b.standardTargetOptions(.{});
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 21:09:32 +01: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 22:31:06 +01: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
const docgen_exe = b.addExecutable("docgen", "doc/docgen.zig");
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 18:06:22 +01: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 18:17:34 +01: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 18:17:34 +01:00
"doc" ++ fs.path.sep_str ++ "langref.html.in",
fix zig build cache dir path
2018-09-12 16:49:46 +01: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);
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 22:41:28 +01:00
const toolchain_step = b.step("test-toolchain", "Run the tests for the toolchain");
add building the self hosted compiler to the main test suite
2018-01-03 23:25:17 +00:00
rename src-self-hosted/ to src/
2020-09-22 02:38:55 +01:00
var test_stage2 = b.addTest("src/test.zig");
allow running the stage2 tests in release mode
2020-08-20 21:16:04 +01:00
test_stage2.setBuildMode(mode);
avoid calling into stage1 backend when AstGen fails The motivation for this commit is that there exists source files which produce ast-check errors, but crash stage1 or otherwise trigger stage1 bugs. Previously to this commit, Zig would run AstGen, collect the compile errors, run stage1, report stage1 compile errors and exit if any, and then report AstGen compile errors. The main change in this commit is to report AstGen errors prior to invoking stage1, and in fact if any AstGen errors occur, do not invoke stage1 at all. This caused most of the compile error tests to fail due to things such as unused local variables and mismatched stage1/stage2 error messages. It was taking a long time to update the test cases one-by-one, so I took this opportunity to unify the stage1 and stage2 testing harness, specifically with regards to compile errors. In this way we can start keeping track of which tests pass for 1, 2, or both. `zig build test-compile-errors` no longer works; it is now integrated into `zig build test-stage2`. This is one step closer to executing compile error tests in parallel; in fact the ThreadPool object is already in scope. There are some cases where the stage1 compile errors were actually better; those are left failing in this commit, to be addressed in a follow-up commit. Other changes in this commit: * build.zig: improve support for -Dstage1 used with the test step. * AstGen: minor cosmetic changes to error messages. * stage2: add -fstage1 and -fno-stage1 flags. This now allows one to download a binary of the zig compiler and use the llvm backend of self-hosted. This was also needed for hooking up the test harness. However, I realized that stage1 calls exit() and also has memory leaks, so had to complicate the test harness by not using this flag after all and instead invoking as a child process. - These CLI flags will disappear once we start shipping the self-hosted compiler as the main compiler. Until then, they can be used to try out the work-in-progress stage2. * stage2: select the LLVM backend by default for release modes, as long as the target architecture is supported by LLVM. * test harness: support setting the optimize mode
2021-06-30 19:27:39 +01:00
test_stage2.addPackagePath("test_cases", "test/cases.zig");
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 18:06:22 +01:00
test_stage2.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 21:39:26 +01: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 19:09:05 +01: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 19:50:26 +01: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 02:21:59 +01: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 04:55:56 +01:00
const skip_libc = b.option(bool, "skip-libc", "Main test suite skips tests that link libc") 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 23:06:44 +01: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 07:10:51 +01: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-16 00:20:43 +01:00
const skip_stage2_tests = b.option(bool, "skip-stage2-tests", "Main test suite skips self-hosted compiler tests") orelse false;
build.zig: add a way to skip installing lib/ files
2021-04-17 02:58:27 +01:00
const skip_install_lib_files = b.option(bool, "skip-install-lib-files", "Do not copy lib/ files to installation prefix") orelse false;
self hosted zig: print usage
2017-10-21 22:31:06 +01: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 08:06:20 +01: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
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 is_stage1 = b.option(bool, "stage1", "Build the stage1 compiler, put stage2 behind a feature flag") orelse false;
ci: windows: proper flags to zig build
2021-04-15 10:02:36 +01:00
const omit_stage2 = b.option(bool, "omit-stage2", "Do not include stage2 behind a feature flag inside stage1") orelse false;
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;
const enable_llvm = b.option(bool, "enable-llvm", "Build self-hosted compiler with LLVM backend enabled") orelse (is_stage1 or 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 06:50:10 +01: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_ve = b.option(
bool,
"llvm-has-ve",
"Whether LLVM has the experimental target ve 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 09:04:54 +01:00
const enable_macos_sdk = b.option(bool, "enable-macos-sdk", "Run tests requiring presence of macOS SDK and frameworks") orelse false;
don't try to find config_h if it's not needed
2020-07-04 02:15:01 +01: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 18:07:19 +01:00
build.zig: add a way to skip installing lib/ files
2021-04-17 02:58:27 +01:00
if (!skip_install_lib_files) {
b.installDirectory(InstallDirectoryOptions{
.source_dir = "lib",
make remaining enums in build.zig snake_case
2021-06-11 09:50:48 +01:00
.install_dir = .lib,
build.zig: add a way to skip installing lib/ files
2021-04-17 02:58:27 +01:00
.install_subdir = "zig",
.exclude_extensions = &[_][]const u8{
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
// exclude files from lib/std/compress/
".gz",
build.zig: add a way to skip installing lib/ files
2021-04-17 02:58:27 +01: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 02:58:27 +01: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 01:18:42 +01:00
.blank_extensions = &[_][]const u8{
"test.zig",
},
build.zig: add a way to skip installing lib/ files
2021-04-17 02:58:27 +01:00
});
}
self hosted zig: print usage
2017-10-21 22:31:06 +01: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 19:15:32 +01:00
if (only_install_lib_files)
return;
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 01:17:37 +01:00
const tracy = b.option([]const u8, "tracy", "Enable Tracy integration. Supply path to Tracy source");
make tracy.zig more feature complete
2021-10-31 14:12:36 +00:00
const tracy_callstack = b.option(bool, "tracy-callstack", "Include callstack information with Tracy data. Does nothing if -Dtracy is not provided") orelse false;
add functionality to trace allocations
2021-10-31 14:16:59 +00:00
const tracy_allocation = b.option(bool, "tracy-allocation", "Include allocation information with Tracy data. Does nothing if -Dtracy is not provided") orelse false;
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;
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 01:17:37 +01:00
const link_libc = b.option(bool, "force-link-libc", "Force self-hosted compiler to link libc") orelse enable_llvm;
build.zig: expose a strip option
2021-02-24 23:36:27 +00:00
const strip = b.option(bool, "strip", "Omit debug information") orelse false;
build.zig: restore the ability to bootstrap with zig0 via option
2022-02-18 06:49:13 +00:00
const use_zig0 = b.option(bool, "zig0", "Bootstrap using zig0") orelse false;
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 01:17:37 +01: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 04:42:36 +01: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: {
if (strip) break :blk @as(u32, 0);
if (mode != .Debug) break :blk 0;
break :blk 4;
};
build.zig: restore the ability to bootstrap with zig0 via option
2022-02-18 06:49:13 +00:00
const main_file: ?[]const u8 = mf: {
if (!is_stage1) break :mf "src/main.zig";
if (use_zig0) break :mf null;
break :mf "src/stage1.zig";
};
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
const exe = b.addExecutable("zig", main_file);
build.zig: expose a strip option
2021-02-24 23:36:27 +00:00
exe.strip = strip;
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 19:15:32 +01:00
exe.install();
exe.setBuildMode(mode);
exe.setTarget(target);
build: make -Dskip-stage2-tests not build stage2 for the test-toolchain step
2021-09-16 19:21:19 +01:00
if (!skip_stage2_tests) {
toolchain_step.dependOn(&exe.step);
}
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 19:15:32 +01:00
b.default_step.dependOn(&exe.step);
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 18:06:22 +01: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 19:15:32 +01:00
Fix compiler builds with tracy on the mingw target
2021-09-16 22:51:29 +01: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;
Fix failing tests and windows link dependencies
2021-09-22 20:39:02 +01:00
test_stage2.want_lto = false;
Fix compiler builds with tracy on the mingw target
2021-09-16 22:51:29 +01: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-27 00:53:23 +01: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 06:50:10 +01: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_ve", llvm_has_ve);
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);
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-27 00:53:23 +01: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 19:15:32 +01:00
if (link_libc) {
exe.linkLibC();
test_stage2.linkLibC();
}
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 12:50:10 +01: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 19:15:32 +01:00
const opt_version_string = b.option([]const u8, "version-string", "Override Zig version string. Default is to find out with git.");
const version = 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 19:15:32 +01: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 19:15:32 +01: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.9.0
2021-12-20 20:13:19 +00:00
// Tagged release version (e.g. 0.9.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.9.0
2021-12-20 20:13:19 +00:00
// Untagged development build (e.g. 0.9.0-dev.2025+ecf0050a9).
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 10:01:47 +01:00
var it = mem.split(u8, 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
const tagged_ancestor = it.next() orelse unreachable;
const commit_height = it.next() orelse unreachable;
const commit_id = it.next() orelse unreachable;
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 19:15:32 +01: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-27 00:53:23 +01:00
exe_options.addOption([:0]const u8, "version", try b.allocator.dupeZ(u8, 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) {
const cmake_cfg = if (static_llvm) null else findAndParseConfigH(b, config_h_path_option);
if (is_stage1) {
const softfloat = b.addStaticLibrary("softfloat", null);
softfloat.setBuildMode(.ReleaseFast);
softfloat.setTarget(target);
softfloat.addIncludePath("deps/SoftFloat-3e-prebuilt");
softfloat.addIncludePath("deps/SoftFloat-3e/source/8086");
softfloat.addIncludePath("deps/SoftFloat-3e/source/include");
softfloat.addCSourceFiles(&softfloat_sources, &[_][]const u8{ "-std=c99", "-O3" });
softfloat.single_threaded = single_threaded;
build.zig: restore the ability to bootstrap with zig0 via option
2022-02-18 06:49:13 +00:00
const zig0 = b.addExecutable("zig0", null);
zig0.addCSourceFiles(&.{"src/stage1/zig0.cpp"}, &exe_cflags);
zig0.addIncludePath("zig-cache/tmp"); // for config.h
zig0.defineCMacro("ZIG_VERSION_MAJOR", b.fmt("{d}", .{zig_version.major}));
zig0.defineCMacro("ZIG_VERSION_MINOR", b.fmt("{d}", .{zig_version.minor}));
zig0.defineCMacro("ZIG_VERSION_PATCH", b.fmt("{d}", .{zig_version.patch}));
zig0.defineCMacro("ZIG_VERSION_STRING", b.fmt("\"{s}\"", .{version}));
for ([_]*std.build.LibExeObjStep{ zig0, exe, test_stage2 }) |artifact| {
artifact.addIncludePath("src");
artifact.addIncludePath("deps/SoftFloat-3e/source/include");
artifact.addIncludePath("deps/SoftFloat-3e-prebuilt");
artifact.defineCMacro("ZIG_LINK_MODE", "Static");
artifact.addCSourceFiles(&stage1_sources, &exe_cflags);
artifact.addCSourceFiles(&optimized_c_sources, &[_][]const u8{ "-std=c99", "-O3" });
artifact.linkLibrary(softfloat);
artifact.linkLibCpp();
}
try addStaticLlvmOptionsToExe(zig0);
const zig1_obj_ext = target.getObjectFormat().fileExt(target.getCpuArch());
const zig1_obj_path = b.pathJoin(&.{ "zig-cache", "tmp", b.fmt("zig1{s}", .{zig1_obj_ext}) });
const zig1_compiler_rt_path = b.pathJoin(&.{ b.pathFromRoot("lib"), "std", "special", "compiler_rt.zig" });
const zig1_obj = zig0.run();
zig1_obj.addArgs(&.{
"src/stage1.zig",
"-target",
try target.zigTriple(b.allocator),
"-mcpu=baseline",
"--name",
"zig1",
"--zig-lib-dir",
b.pathFromRoot("lib"),
b.fmt("-femit-bin={s}", .{b.pathFromRoot(zig1_obj_path)}),
"-fcompiler-rt",
"-lc",
});
{
zig1_obj.addArgs(&.{ "--pkg-begin", "build_options" });
zig1_obj.addFileSourceArg(exe_options.getSource());
zig1_obj.addArgs(&.{ "--pkg-end", "--pkg-begin", "compiler_rt", zig1_compiler_rt_path, "--pkg-end" });
}
switch (mode) {
.Debug => {},
.ReleaseFast => {
zig1_obj.addArg("-OReleaseFast");
zig1_obj.addArg("--strip");
},
.ReleaseSafe => {
zig1_obj.addArg("-OReleaseSafe");
zig1_obj.addArg("--strip");
},
.ReleaseSmall => {
zig1_obj.addArg("-OReleaseSmall");
zig1_obj.addArg("--strip");
},
}
if (single_threaded orelse false) {
zig1_obj.addArg("-fsingle-threaded");
}
if (use_zig0) {
exe.step.dependOn(&zig1_obj.step);
exe.addObjectFile(zig1_obj_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
// This is intentionally a dummy path. stage1.zig tries to @import("compiler_rt") in case
// of being built by cmake. But when built by zig it's gonna get a compiler_rt so that
// is pointless.
exe.addPackagePath("compiler_rt", "src/empty.zig");
}
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) {
b.addSearchPrefix(cfg.cmake_prefix_path);
}
try addCmakeCfgOptionsToExe(b, cfg, exe, use_zig_libcxx);
build.zig: fix test-stage2 regression with -Denable-llvm Regressed in cc9eb9e90fec961a74e90e1ab3d66a7b8ec14f47 due to a merge conflict.
2022-02-18 03:46:40 +00:00
try addCmakeCfgOptionsToExe(b, cfg, test_stage2, 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);
build.zig: fix test-stage2 regression with -Denable-llvm Regressed in cc9eb9e90fec961a74e90e1ab3d66a7b8ec14f47 due to a merge conflict.
2022-02-18 03:46:40 +00:00
try addStaticLlvmOptionsToExe(test_stage2);
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-27 00:53:23 +01: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 19:15:32 +01: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-27 00:53:23 +01: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 12:50:10 +01: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-27 00:53:23 +01: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);
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-27 00:53:23 +01:00
exe_options.addOption(bool, "is_stage1", is_stage1);
exe_options.addOption(bool, "omit_stage2", omit_stage2);
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 19:15:32 +01:00
if (tracy) |tracy_path| {
const client_cpp = fs.path.join(
b.allocator,
&[_][]const u8{ tracy_path, "TracyClient.cpp" },
) catch unreachable;
Fix compiler builds with tracy on the mingw target
2021-09-16 22:51:29 +01: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 22:51:29 +01: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 01:17:37 +01: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 19:15:32 +01:00
exe.linkLibC();
Fix compiler builds with tracy on the mingw target
2021-09-16 22:51:29 +01: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 19:15:32 +01:00
}
convert compare-output tests to use zig build system
2017-04-19 06:13:15 +01:00
const test_filter = b.option([]const u8, "test-filter", "Skip tests that do not match filter");
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-27 00:53:23 +01:00
const test_stage2_options = b.addOptions();
test_stage2.addOptions("build_options", test_stage2_options);
test_stage2_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 12:50:10 +01:00
test_stage2_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-27 00:53:23 +01:00
test_stage2_options.addOption(bool, "skip_non_native", skip_non_native);
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 23:06:44 +01:00
test_stage2_options.addOption(bool, "skip_stage1", skip_stage1);
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-27 00:53:23 +01:00
test_stage2_options.addOption(bool, "is_stage1", is_stage1);
test_stage2_options.addOption(bool, "omit_stage2", omit_stage2);
test_stage2_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 06:50:10 +01:00
test_stage2_options.addOption(bool, "llvm_has_m68k", llvm_has_m68k);
test_stage2_options.addOption(bool, "llvm_has_csky", llvm_has_csky);
test_stage2_options.addOption(bool, "llvm_has_ve", llvm_has_ve);
test_stage2_options.addOption(bool, "llvm_has_arc", llvm_has_arc);
zig build: promote qemu, wine, wasmtime, darling, and rosetta from zig-specific options to generally recognized zig build options that any project can take advantage of. See the updated usage text for more details.
2021-12-02 22:42:59 +00:00
test_stage2_options.addOption(bool, "enable_qemu", b.enable_qemu);
test_stage2_options.addOption(bool, "enable_wine", b.enable_wine);
test_stage2_options.addOption(bool, "enable_wasmtime", b.enable_wasmtime);
test_stage2_options.addOption(bool, "enable_rosetta", b.enable_rosetta);
test_stage2_options.addOption(bool, "enable_darling", b.enable_darling);
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-27 00:53:23 +01:00
test_stage2_options.addOption(u32, "mem_leak_frames", mem_leak_frames * 2);
zig build: promote qemu, wine, wasmtime, darling, and rosetta from zig-specific options to generally recognized zig build options that any project can take advantage of. See the updated usage text for more details.
2021-12-02 22:42:59 +00:00
test_stage2_options.addOption(?[]const u8, "glibc_runtimes_dir", b.glibc_runtimes_dir);
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-27 00:53:23 +01:00
test_stage2_options.addOption([:0]const u8, "version", try b.allocator.dupeZ(u8, version));
test_stage2_options.addOption(std.SemanticVersion, "semver", semver);
stage2 tests: support the -Denable-qemu options and friends
2020-08-04 23:32:16 +01: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 01:18:43 +01:00
const test_stage2_step = b.step("test-stage2", "Run the stage2 compiler tests");
test_stage2_step.dependOn(&test_stage2.step);
ci: drone: disable stage2 tests See #8545
2021-04-16 00:20:43 +01:00
if (!skip_stage2_tests) {
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 22:41:28 +01:00
toolchain_step.dependOn(test_stage2_step);
ci: drone: disable stage2 tests See #8545
2021-04-16 00:20:43 +01: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 01:18:43 +01: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 19:50:26 +01: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 21:39:26 +01: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 19:50:26 +01: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
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 22:41:28 +01:00
toolchain_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);
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 10:03:44 +01:00
toolchain_step.dependOn(tests.addPkgTests(
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 05:44:38 +01: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 10:03:44 +01:00
"behavior",
"Run the behavior tests",
modes,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 18:06:22 +01:00
false, // 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 10:03:44 +01:00
skip_non_native,
skip_libc,
));
toolchain_step.dependOn(tests.addPkgTests(
b,
test_filter,
"lib/std/special/compiler_rt.zig",
"compiler-rt",
"Run the compiler_rt tests",
modes,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 18:06:22 +01: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 10:03:44 +01:00
skip_non_native,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 18:06:22 +01:00
true, // skip_libc
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 10:03:44 +01:00
));
toolchain_step.dependOn(tests.addPkgTests(
b,
test_filter,
"lib/std/special/c.zig",
"minilibc",
"Run the mini libc tests",
modes,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 18:06:22 +01: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 10:03:44 +01:00
skip_non_native,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 18:06:22 +01:00
true, // skip_libc
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 10:03:44 +01: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 22:41:28 +01:00
toolchain_step.dependOn(tests.addCompareOutputTests(b, test_filter, modes));
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 09:04:54 +01:00
toolchain_step.dependOn(tests.addStandaloneTests(b, test_filter, modes, skip_non_native, enable_macos_sdk, target));
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 22:41:28 +01:00
toolchain_step.dependOn(tests.addStackTraceTests(b, test_filter, modes));
toolchain_step.dependOn(tests.addCliTests(b, test_filter, modes));
toolchain_step.dependOn(tests.addAssembleAndLinkTests(b, test_filter, modes));
toolchain_step.dependOn(tests.addRuntimeSafetyTests(b, test_filter, modes));
toolchain_step.dependOn(tests.addTranslateCTests(b, test_filter));
ci: aarch64-linux: disable run-translated-c tests See #8537
2021-04-15 07:10:51 +01:00
if (!skip_run_translated_c) {
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 22:41:28 +01:00
toolchain_step.dependOn(tests.addRunTranslatedCTests(b, test_filter, target));
ci: aarch64-linux: disable run-translated-c tests See #8537
2021-04-15 07:10:51 +01: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
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 22:41:28 +01:00
// toolchain_step.dependOn(tests.addGenHTests(b, test_filter));
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 10:03:44 +01:00
const std_step = tests.addPkgTests(
b,
test_filter,
"lib/std/std.zig",
"std",
"Run the standard library tests",
modes,
false,
skip_non_native,
skip_libc,
);
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 22:41:28 +01:00
const test_step = b.step("test", "Run all the tests");
test_step.dependOn(toolchain_step);
test_step.dependOn(std_step);
build system: add -Dskip-release option to test faster
2018-07-11 19:09:05 +01:00
test_step.dependOn(docs_step);
convert compare-output tests to use zig build system
2017-04-19 06:13:15 +01: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 21:09:32 +01: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",
b.fmt("{s}{s}{s}", .{ exe.target.libPrefix(), "zigcpp", exe.target.staticLibSuffix() }),
}) 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);
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 21:09:32 +01:00
if (use_zig_libcxx) {
exe.linkLibCpp();
} else {
const need_cpp_includes = true;
// System -lc++ must be used because in this code path we are attempting to link
// against system-provided LLVM, Clang, LLD.
if (exe.target.getOsTag() == .linux) {
// First we try to static link against gcc libstdc++. If that doesn't work,
// we fall back to -lc++ and cross our fingers.
addCxxKnownPath(b, cfg, exe, "libstdc++.a", "", need_cpp_includes) catch |err| switch (err) {
error.RequiredLibraryNotFound => {
exe.linkSystemLibrary("c++");
},
else => |e| return e,
};
exe.linkSystemLibrary("unwind");
} else if (exe.target.isFreeBSD()) {
try addCxxKnownPath(b, cfg, exe, "libc++.a", null, need_cpp_includes);
exe.linkSystemLibrary("pthread");
} else if (exe.target.getOsTag() == .openbsd) {
try addCxxKnownPath(b, cfg, exe, "libc++.a", null, need_cpp_includes);
try addCxxKnownPath(b, cfg, exe, "libc++abi.a", null, need_cpp_includes);
} else if (exe.target.isDarwin()) {
exe.linkSystemLibrary("c++");
}
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 20:58:16 +01:00
exe.linkSystemLibrary("z");
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++");
if (exe.target.getOs().tag == .windows) {
exe.linkSystemLibrary("version");
exe.linkSystemLibrary("uuid");
Fix failing tests and windows link dependencies
2021-09-22 20:39:02 +01:00
exe.linkSystemLibrary("ole32");
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
}
}
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 19:05:42 +01: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
// cc -E -Wp,-v -xc++ /dev/null
if (need_cpp_includes) {
// I used these temporarily for testing something but we obviously need a
// more general purpose solution here.
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("/nix/store/fvf3qjqa5qpcjjkq37pb6ypnk1mzhf5h-gcc-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0/../../../../include/c++/9.3.0");
//exe.addIncludePath("/nix/store/fvf3qjqa5qpcjjkq37pb6ypnk1mzhf5h-gcc-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0/../../../../include/c++/9.3.0/x86_64-unknown-linux-gnu");
//exe.addIncludePath("/nix/store/fvf3qjqa5qpcjjkq37pb6ypnk1mzhf5h-gcc-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0/../../../../include/c++/9.3.0/backward");
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 10:01:47 +01: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_binary_dir: []const u8,
cmake_prefix_path: []const u8,
cxx_compiler: []const u8,
lld_include_dir: []const u8,
lld_libraries: []const u8,
clang_libraries: []const u8,
llvm_libraries: []const u8,
dia_guids_lib: []const u8,
};
const max_config_h_bytes = 1 * 1024 * 1024;
fn findAndParseConfigH(b: *Builder, config_h_path_option: ?[]const u8) ?CMakeConfig {
const config_h_text: []const u8 = if (config_h_path_option) |config_h_path| blk: {
break :blk fs.cwd().readFileAlloc(b.allocator, config_h_path, max_config_h_bytes) catch unreachable;
} else blk: {
// TODO this should stop looking for config.h once it detects we hit the
// zig source root directory.
var check_dir = fs.path.dirname(b.zig_exe).?;
while (true) {
var dir = fs.cwd().openDir(check_dir, .{}) catch unreachable;
defer dir.close();
break :blk dir.readFileAlloc(b.allocator, "config.h", max_config_h_bytes) catch |err| switch (err) {
error.FileNotFound => {
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.?;
continue;
},
else => unreachable,
};
} else unreachable; // TODO should not need `else unreachable`.
};
var ctx: CMakeConfig = .{
.cmake_binary_dir = undefined,
.cmake_prefix_path = undefined,
.cxx_compiler = undefined,
.lld_include_dir = undefined,
.lld_libraries = undefined,
.clang_libraries = undefined,
.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",
},
.{
.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",
},
};
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 10:01:47 +01: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 10:01:47 +01:00
var it = mem.split(u8, line, "\"");
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
_ = it.next().?; // skip the stuff before the quote
const quoted = it.next().?; // the stuff inside the quote
@field(ctx, mapping.field) = toNativePathSep(b, quoted);
}
}
}
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 stage1_sources = [_][]const u8{
"src/stage1/analyze.cpp",
build: rename ast_render in build.zig. Signed-off-by: Takeshi Yoneda <takeshi@tetrate.io>
2021-05-30 12:28:46 +01:00
"src/stage1/astgen.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/stage1/bigfloat.cpp",
"src/stage1/bigint.cpp",
"src/stage1/buffer.cpp",
"src/stage1/codegen.cpp",
"src/stage1/dump_analysis.cpp",
"src/stage1/errmsg.cpp",
"src/stage1/error.cpp",
"src/stage1/heap.cpp",
"src/stage1/ir.cpp",
"src/stage1/ir_print.cpp",
"src/stage1/mem.cpp",
"src/stage1/os.cpp",
"src/stage1/parser.cpp",
"src/stage1/range_set.cpp",
"src/stage1/stage1.cpp",
"src/stage1/target.cpp",
"src/stage1/tokenizer.cpp",
"src/stage1/util.cpp",
"src/stage1/softfloat_ext.cpp",
};
const optimized_c_sources = [_][]const u8{
"src/stage1/parse_f128.c",
};
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 01:33:16 +01: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 01:18:43 +01: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 16:57:28 +01: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",
};
const lld_libs = [_][]const u8{
"lldDriver",
"lldMinGW",
"lldELF",
"lldCOFF",
"lldMachO",
"lldWasm",
"lldReaderWriter",
"lldCore",
"lldYAML",
"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 18:58:53 +01: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",
build.zig: update llvm libs
2021-04-15 18:43:39 +01: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 18:43:39 +01: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",
"LLVMX86Disassembler",
"LLVMX86AsmParser",
build.zig: update llvm libs
2021-04-15 18:43:39 +01: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 18:43:39 +01: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 20:40:07 +01: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",
"LLVMSystemZDisassembler",
"LLVMSystemZAsmParser",
build.zig: update llvm libs
2021-04-15 18:43:39 +01: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 18:43:39 +01: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 18:43:39 +01: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 18:43:39 +01: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 18:43:39 +01: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 18:43:39 +01: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 18:43:39 +01: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 18:43:39 +01: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 18:43:39 +01: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",
"LLVMAMDGPUDisassembler",
"LLVMAMDGPUAsmParser",
build.zig: update llvm libs
2021-04-15 18:43:39 +01: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 18:43:39 +01: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 18:43:39 +01: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 20:40:07 +01:00
"LLVMOrcTargetProcess",
"LLVMOrcShared",
"LLVMDWP",
build.zig: update llvm libs
2021-04-15 18:43:39 +01:00
"LLVMSymbolize",
"LLVMDebugInfoPDB",
"LLVMDebugInfoGSYM",
"LLVMOption",
"LLVMObjectYAML",
"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 18:43:39 +01: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 18:43:39 +01: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 list of LLVM libs companion commit to 0f35a1f37ade9cf25707c41711b352174f1e2789 fixes compiling with a dev kit.
2021-10-02 20:40:07 +01:00
"LLVMDebugInfoMSF",
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
"LLVMDebugInfoDWARF",
build.zig: update llvm libs
2021-04-15 18:43:39 +01: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 18:43:39 +01: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",
"LLVMObject",
"LLVMTextAPI",
"LLVMMCParser",
"LLVMMC",
"LLVMDebugInfoCodeView",
build.zig: update llvm libs
2021-04-15 18:43:39 +01:00
"LLVMBitReader",
"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