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

1052 lines
40 KiB
Zig
Raw Normal View History

self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
const std = @import("std");
stage2: improvements aimed at std lib integration * AstGen: emit decl lookup ZIR instructions rather than directly looking up decls in AstGen. This is necessary because we want to reuse the same immutable ZIR code for multiple generic instantiations (and comptime function calls). * AstGen: fix using members_len instead of fields_len for struct decls. * structs: the struct_decl ZIR instruction is now also a block. This is so that the type expressions, default field value expressions, and alignment expressions can be evaluated in a scope that contains the decls from the struct namespace itself. * Add "std" and "builtin" packages to the builtin package. * Don't try to build glibc, musl, or mingw-w64 when using `-ofmt=c`. * builtin.zig is generated without `usingnamespace`. * builtin.zig takes advantage of `std.zig.fmtId` for CPU features. * A first pass at implementing `usingnamespace`. It's problematic and should either be deleted, or polished, before merging this branch. * Sema: allow explicitly specifying the namespace in which to look up Decls. This is used by `struct_decl` in order to put the decls from the struct namespace itself in scope when evaluating the type expressions, default value expressions, and alignment expressions. * Module: fix `analyzeNamespace` assuming that it is the top-level root declaration node. * Sema: implement comptime and runtime cmp operator. * Sema: implement peer type resolution for enums and enum literals. * Pull in the changes from master branch: 262e09c482d98a78531c049a18b7f24146fe157f. * ZIR: complete out simple_ptr_type debug printing
2021-04-12 23:44:51 +00:00
const builtin = std.builtin;
self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
const Builder = std.build.Builder;
convert compare-output tests to use zig build system
2017-04-19 05:13:15 +00:00
const tests = @import("test/tests.zig");
self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
const BufMap = std.BufMap;
const warn = std.debug.warn;
const mem = std.mem;
const ArrayList = std.ArrayList;
const io = std.io;
clean up references to os
2019-05-26 17:17:34 +00:00
const fs = std.fs;
move some of the installation from cmake to zig build This moves the installation of shipped source files from large CMakeLists.txt lists to zig build recursive directory installation. On my computer a cmake `make install` takes 2.4 seconds even when it has to do nothing, and prints a lot of unnecessary lines to stdout that say "up-to-date: [some file it is installing]". After this commit, the default output of `make` is down to 1 second, and it does not print any junk to stdout. Further, a `make install` is no longer required and `make` is sufficient. This closes #2874. It also closes #2585. `make` now always invokes `zig build` for installing files and libuserland.a, and zig's own caching system makes that go fast.
2019-07-14 07:06:20 +00:00
const InstallDirectoryOptions = std.build.InstallDirectoryOptions;
start moving `zig cc` to stage2 * build.zig: repair the ability to link against llvm, clang, and lld * move the zig cc arg parsing logic to stage2 - the preprocessor flag is still TODO - the clang arg iterator code is improved to use slices instead of raw pointers because it no longer has to deal with an extern struct. * clean up error printing with a `fatal` function and use log API for messages rather than std.debug.print * add support for more CLI options to stage2 & update usage text - hooking up most of these new options is TODO * clean up the way libc and libc++ are detected via command line options. target information is used to determine if any of the libc candidate names are chosen. * add native library directory detection * implement the ability to invoke clang from stage2 * introduce a build_options.have_llvm so we can comptime branch on whether LLVM is linked in or not.
2020-09-04 03:23:00 +00:00
const assert = std.debug.assert;
convert compare-output tests to use zig build system
2017-04-19 05:13:15 +00:00
start the 0.9.0 release cycle
2021-06-04 18:28:39 +00:00
const zig_version = std.builtin.Version{ .major = 0, .minor = 9, .patch = 0 };
stage2: implement zig version
2020-08-15 21:17:40 +00:00
use * for pointer type instead of & See #770 To help automatically translate code, see the zig-fmt-pointer-reform-2 branch. This will convert all & into *. Due to the syntax ambiguity (which is why we are making this change), even address-of & will turn into *, so you'll have to manually fix thes instances. You will be guaranteed to get compile errors for them - expected 'type', found 'foo'
2018-05-31 14:56:59 +00:00
pub fn build(b: *Builder) !void {
zig build: search upwards for build.zig file closes #2587
2019-07-04 21:43:56 +00:00
b.setPreferredReleaseMode(.ReleaseFast);
self hosted zig: print usage
2017-10-21 21:31:06 +00:00
const mode = b.standardReleaseOptions();
stage2: remove some dead code, fix build on aarch64
2020-07-21 18:18:51 +00:00
const target = b.standardTargetOptions(.{});
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
const single_threaded = b.option(bool, "single-threaded", "Build artifacts that run in single threaded mode") orelse false;
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
const use_zig_libcxx = b.option(bool, "use-zig-libcxx", "If libc++ is needed, use zig's bundled version, don't try to integrate with the system") orelse false;
self hosted zig: print usage
2017-10-21 21:31:06 +00:00
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
var docgen_exe = b.addExecutable("docgen", "doc/docgen.zig");
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
docgen_exe.single_threaded = single_threaded;
std.io: introduce buffered I/O and change API I started working on #465 and made some corresponding std.io API changes. New structs: * std.io.FileInStream * std.io.FileOutStream * std.io.BufferedOutStream * std.io.BufferedInStream Removed: * std.io.File.in_stream * std.io.File.out_stream Now instead of &file.out_stream or &file.in_stream to get access to the stream API for a file, you get it like this: var file_in_stream = io.FileInStream.init(&file); const in_stream = &file_in_stream.stream; var file_out_stream = io.FileOutStream.init(&file); const out_stream = &file_out_stream.stream; This is evidence that we might not need any OOP features - See #130.
2017-11-07 08:22:27 +00:00
clean up references to os
2019-05-26 17:17:34 +00:00
const rel_zig_exe = try fs.path.relative(b.allocator, b.build_root, b.zig_exe);
const langref_out_path = fs.path.join(
fixups, and modify std.mem.join and std.os.path.resolve API * zig fmt * std.mem.join takes a slice of slices instead of var args * std.mem.join takes a separator slice rather than byte, and always inserts it. Previously it would not insert the separator if there already was one, violating the documented behavior. * std.mem.join calculates exactly the correct amount to allocate and has no call to allocator.shrink() * bring back joinWindows and joinPosix and the corresponding tests. it is intended to be able to call these functions from any OS. * rename std.os.path.resolveSlice to resolve (now resolve takes a slice of slices instead of var args)
2019-02-07 05:42:41 +00:00
b.allocator,
remove type coercion from array values to references * Implements #3768. This is a sweeping breaking change that requires many (trivial) edits to Zig source code. Array values no longer coerced to slices; however one may use `&` to obtain a reference to an array value, which may then be coerced to a slice. * Adds `IrInstruction::dump`, for debugging purposes. It's useful to call to inspect the instruction when debugging Zig IR. * Fixes bugs with result location semantics. See the new behavior test cases, and compile error test cases. * Fixes bugs with `@typeInfo` not properly resolving const values. * Behavior tests are passing but std lib tests are not yet. There is more work to do before merging this branch.
2019-11-27 08:30:39 +00:00
&[_][]const u8{ b.cache_root, "langref.html" },
fixups, and modify std.mem.join and std.os.path.resolve API * zig fmt * std.mem.join takes a slice of slices instead of var args * std.mem.join takes a separator slice rather than byte, and always inserts it. Previously it would not insert the separator if there already was one, violating the documented behavior. * std.mem.join calculates exactly the correct amount to allocate and has no call to allocator.shrink() * bring back joinWindows and joinPosix and the corresponding tests. it is intended to be able to call these functions from any OS. * rename std.os.path.resolveSlice to resolve (now resolve takes a slice of slices instead of var args)
2019-02-07 05:42:41 +00:00
) catch unreachable;
breaking changes to zig build API and improved caching * in Zig build scripts, getOutputPath() is no longer a valid function to call, unless setOutputDir() was used, or within a custom make() function. Instead there is more convenient API to use which takes advantage of the caching system. Search this commit diff for `exe.run()` for an example. * Zig build by default enables caching. All build artifacts will go into zig-cache. If you want to access build artifacts in a convenient location, it is recommended to add an `install` step. Otherwise you can use the `run()` API mentioned above to execute programs directly from their location in the cache. Closes #330. `addSystemCommand` is available for programs not built with Zig build. * Please note that Zig does no cache evicting yet. You may have to manually delete zig-cache directories periodically to keep disk usage down. It's planned for this to be a simple Least Recently Used eviction system eventually. * `--output`, `--output-lib`, and `--output-h` are removed. Instead, use `--output-dir` which defaults to the current working directory. Or take advantage of `--cache on`, which will print the main output path to stdout, and the other artifacts will be in the same directory with predictable file names. `--disable-gen-h` is available when one wants to prevent .h file generation. * `@cImport` is always independently cached now. Closes #2015. It always writes the generated Zig code to disk which makes debug info and compile errors better. No more "TODO: remember C source location to display here" * Fix .d file parsing. (Fixes the MacOS CI failure) * Zig no longer creates "temporary files" other than inside a zig-cache directory. This breaks the CLI API that Godbolt uses. The suggested new invocation can be found in this commit diff, in the changes to `test/cli.zig`.
2019-03-09 03:53:35 +00:00
var docgen_cmd = docgen_exe.run();
remove type coercion from array values to references * Implements #3768. This is a sweeping breaking change that requires many (trivial) edits to Zig source code. Array values no longer coerced to slices; however one may use `&` to obtain a reference to an array value, which may then be coerced to a slice. * Adds `IrInstruction::dump`, for debugging purposes. It's useful to call to inspect the instruction when debugging Zig IR. * Fixes bugs with result location semantics. See the new behavior test cases, and compile error test cases. * Fixes bugs with `@typeInfo` not properly resolving const values. * Behavior tests are passing but std lib tests are not yet. There is more work to do before merging this branch.
2019-11-27 08:30:39 +00:00
docgen_cmd.addArgs(&[_][]const u8{
docgen: support executing exe code examples See #465
2018-01-17 06:50:35 +00:00
rel_zig_exe,
clean up references to os
2019-05-26 17:17:34 +00:00
"doc" ++ fs.path.sep_str ++ "langref.html.in",
fix zig build cache dir path
2018-09-12 15:49:46 +00:00
langref_out_path,
std.io: introduce buffered I/O and change API I started working on #465 and made some corresponding std.io API changes. New structs: * std.io.FileInStream * std.io.FileOutStream * std.io.BufferedOutStream * std.io.BufferedInStream Removed: * std.io.File.in_stream * std.io.File.out_stream Now instead of &file.out_stream or &file.in_stream to get access to the stream API for a file, you get it like this: var file_in_stream = io.FileInStream.init(&file); const in_stream = &file_in_stream.stream; var file_out_stream = io.FileOutStream.init(&file); const out_stream = &file_out_stream.stream; This is evidence that we might not need any OOP features - See #130.
2017-11-07 08:22:27 +00:00
});
docgen_cmd.step.dependOn(&docgen_exe.step);
const docs_step = b.step("docs", "Build documentation");
docs_step.dependOn(&docgen_cmd.step);
Azure CI: Test std.* and the rest separately On CI, we have been running into OOM issues when running the test suite on Windows for quite some time. Unfortunately, we are very close to having the same issues on Linux as well. Some additional comptime work immediately makes these builds fail as well. Add a new `test-toolchain` step, that tests everything except `std.*` and documentation. On CI, call `test-toolchain`, `test-std` and `docs` separately instead of the `test` big hammer that emcompasses all of them. Change the special case we made for Windows to the same code as other platforms. This is a stopgap measure that stage2 will eventually make useless. Until then, it gives us some headroom. Change `linux_script` by the way to only output the log of failing steps. This shrinks the Linux CI log from a bazilion lines down to something more humanely manageable.
2021-04-30 21:41:28 +00:00
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 01:38:55 +00:00
var test_stage2 = b.addTest("src/test.zig");
allow running the stage2 tests in release mode
2020-08-20 20:16:04 +00: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 18:27:39 +00:00
test_stage2.addPackagePath("test_cases", "test/cases.zig");
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00: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 20:39:26 +00:00
const skip_debug = b.option(bool, "skip-debug", "Main test suite skips debug builds") orelse false;
build system: add -Dskip-release option to test faster
2018-07-11 18:09:05 +00:00
const skip_release = b.option(bool, "skip-release", "Main test suite skips release builds") orelse false;
ci: skip release-small tests to save time we keep hitting the limit on how long CI tests take to run.
2018-09-12 18:50:26 +00:00
const skip_release_small = b.option(bool, "skip-release-small", "Main test suite skips release-small builds") orelse skip_release;
const skip_release_fast = b.option(bool, "skip-release-fast", "Main test suite skips release-fast builds") orelse skip_release;
const skip_release_safe = b.option(bool, "skip-release-safe", "Main test suite skips release-safe builds") orelse skip_release;
slice types no longer have field access * fix crash when doing field access of slice types. closes #2486 * remove the deprecated Child property from slice types * add -Dskip-non-native build option to build script
2019-05-15 01:21:59 +00:00
const skip_non_native = b.option(bool, "skip-non-native", "Main test suite skips non-native builds") orelse false;
significantly increase test coverage * add zig build option `-Dskip-libc` to skip tests that build libc (e.g. if you don't want to wait for musl to build) * add `-Denable-wine` option which uses wine to run cross compiled windows tests on non-windows hosts * add `-Denable-qemu` option which uses qemu to run cross compiled foreign architecture tests * add `-Denable-foreign-glibc=path` option which combined with `-Denable-qemu` enables running cross compiled tests that link against glibc. See https://github.com/ziglang/zig/wiki/Updating-libc#glibc for how to produce this directory. * the test matrix is done manually. release test builds are only enabled by default for the native target. this should save us some CI time, while still providing decent coverage of release builds. - add test coverage for `x86_64-linux-musl -lc` (building musl libc) - add test coverage for `x86_64-linux-gnu -lc` (building glibc) - add test coverage for `aarch64v8_5a-linux-none` - add test coverage for `aarch64v8_5a-linux-musl -lc` (building musl libc) - add test coverage for `aarch64v8_5a-linux-gnu -lc` (building glibc) - add test coverage for `arm-linux-none` - test coverage for `arm-linux-musleabihf -lc` (building musl libc) is disabled due to #3286 - test coverage for `arm-linux-gnueabihf -lc` (building glibc) is disabled due to #3287 - test coverage for `x86_64-windows-gnu -lc` (building mingw-w64) is disabled due to #3285 * enable qemu testing on the Linux CI job. There's not really a good reason to enable wine, since we have a Windows CI job as well. * remove the no longer needed `--build-file ../build.zig` from CI scripts * fix bug in glibc compilation where it wasn't properly reading the abi list txt files, resulting in "key not found" error. * std.build.Target gains: - isNetBSD - isLinux - osRequiresLibC - getArchPtrBitWidth - getExternalExecutor * zig build system gains support for enabling wine and enabling qemu. `artifact.enable_wine = true;`, `artifact.enable_qemu = true;`. This communicates that the system has these tools installed and the build system will use them to run tests. * zig build system gains support for overriding the dynamic linker of an executable artifact. * fix std.c.lseek prototype. makes behavior tests for arm-linux-musleabihf pass. * disable std lib tests that are failing on ARM. See #3288, #3289 * provide `std.os.off_t`. * disable some of the compiler_rt symbols for arm 32 bit. Fixes compiler_rt tests for arm 32 bit * add __stack_chk_guard when linking against glibc. Fixes std lib tests for aarch64-linux-gnu * workaround for "unable to inline function" using `@inlineCall`. Fixes compiler_rt tests for arm 32 bit.
2019-09-22 03:55:56 +00:00
const skip_libc = b.option(bool, "skip-libc", "Main test suite skips tests that link libc") orelse false;
ci: skip compile error tests on Windows We're up against the 6 hour limit so this is a time-saving workaround. Compile error tests are generally not OS-specific so the coverage from the other platforms should be sufficient.
2020-08-31 21:54:05 +00:00
const skip_compile_errors = b.option(bool, "skip-compile-errors", "Main test suite skips compile error tests") orelse false;
ci: aarch64-linux: disable run-translated-c tests See #8537
2021-04-15 06:10:51 +00:00
const skip_run_translated_c = b.option(bool, "skip-run-translated-c", "Main test suite skips run-translated-c tests") orelse false;
ci: drone: disable stage2 tests See #8545
2021-04-15 23:20:43 +00:00
const skip_stage2_tests = b.option(bool, "skip-stage2-tests", "Main test suite skips self-hosted compiler tests") orelse false;
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00: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 21:31:06 +00:00
move some of the installation from cmake to zig build This moves the installation of shipped source files from large CMakeLists.txt lists to zig build recursive directory installation. On my computer a cmake `make install` takes 2.4 seconds even when it has to do nothing, and prints a lot of unnecessary lines to stdout that say "up-to-date: [some file it is installing]". After this commit, the default output of `make` is down to 1 second, and it does not print any junk to stdout. Further, a `make install` is no longer required and `make` is sufficient. This closes #2874. It also closes #2585. `make` now always invokes `zig build` for installing files and libuserland.a, and zig's own caching system makes that go fast.
2019-07-14 07:06:20 +00:00
const only_install_lib_files = b.option(bool, "lib-files-only", "Only install library files") orelse false;
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 09:02:36 +00: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 05:50:10 +00:00
const llvm_has_m68k = b.option(
bool,
"llvm-has-m68k",
"Whether LLVM has the experimental target m68k enabled",
) orelse false;
const llvm_has_csky = b.option(
bool,
"llvm-has-csky",
"Whether LLVM has the experimental target csky enabled",
) orelse false;
const llvm_has_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 08:04:54 +00:00
const enable_macos_sdk = b.option(bool, "enable-macos-sdk", "Run tests requiring presence of macOS SDK and frameworks") orelse false;
don't try to find config_h if it's not needed
2020-07-04 01:15:01 +00:00
const config_h_path_option = b.option([]const u8, "config_h", "Path to the generated config.h");
build.zig supports specifying config.h location explicitly also it does not try to run llvm-config executable when -Dlib-files-only This fixes cross-compiling using the bootstrap repository.
2020-04-06 17:07:19 +00:00
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00:00
if (!skip_install_lib_files) {
b.installDirectory(InstallDirectoryOptions{
.source_dir = "lib",
make remaining enums in build.zig snake_case
2021-06-11 08:50:48 +00:00
.install_dir = .lib,
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00:00
.install_subdir = "zig",
.exclude_extensions = &[_][]const u8{
"README.md",
".z.0",
".z.9",
".gz",
"rfc1951.txt",
},
build.zig: blank out "*test.zig" files instead of omit Now that `@import` of a non-existent file name is a compile error, the Zig installation needs to include files that end with test.zig. However we still want to avoid bloat in the installation size, so we blank them out instead of omitting them entirely. Now AstGen of the full standard library can complete successfully on a Zig installation rather than erroring out with file not found.
2021-05-19 00:18:42 +00:00
.blank_extensions = &[_][]const u8{
"test.zig",
},
build.zig: add a way to skip installing lib/ files
2021-04-17 01:58:27 +00:00
});
}
self hosted zig: print usage
2017-10-21 21:31:06 +00:00
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
if (only_install_lib_files)
return;
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 00:17:37 +00:00
const tracy = b.option([]const u8, "tracy", "Enable Tracy integration. Supply path to Tracy source");
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;
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 00:17:37 +00:00
build.zig: add -Dmem-leak-frames option to configure how many stack frames to save with every allocation, in case it leaks and needs to get printed on process termination.
2021-05-04 03:42:36 +00:00
const mem_leak_frames: u32 = b.option(u32, "mem-leak-frames", "How many stack frames to print when a memory leak occurs. Tests get 2x this amount.") orelse blk: {
if (strip) break :blk @as(u32, 0);
if (mode != .Debug) break :blk 0;
break :blk 4;
};
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 main_file = if (is_stage1) "src/stage1.zig" else "src/main.zig";
fix wrong entrypoint, undefined package, and wrong build option
2020-12-05 05:24:04 +00:00
var 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 18:15:32 +00: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 18:21:19 +00:00
if (!skip_stage2_tests) {
toolchain_step.dependOn(&exe.step);
}
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
b.default_step.dependOn(&exe.step);
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
exe.single_threaded = single_threaded;
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
if (target.isWindows() and target.getAbi() == .gnu) {
// LTO is currently broken on mingw, this can be removed when it's fixed.
exe.want_lto = false;
Fix failing tests and windows link dependencies
2021-09-22 19:39:02 +00:00
test_stage2.want_lto = false;
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
}
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
const exe_options = b.addOptions();
exe.addOptions("build_options", exe_options);
exe_options.addOption(u32, "mem_leak_frames", mem_leak_frames);
exe_options.addOption(bool, "skip_non_native", skip_non_native);
exe_options.addOption(bool, "have_llvm", enable_llvm);
stage2: update LLVM backend to for LLVM 13 There was some new code in master branch enumerating all the targets and a new target was added so we needed to add the glue code. This commit also introduces some build options to support experimental LLVM targets.
2021-09-01 05:50:10 +00:00
exe_options.addOption(bool, "llvm_has_m68k", llvm_has_m68k);
exe_options.addOption(bool, "llvm_has_csky", llvm_has_csky);
exe_options.addOption(bool, "llvm_has_ve", llvm_has_ve);
exe_options.addOption(bool, "llvm_has_arc", llvm_has_arc);
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
if (enable_llvm) {
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 cmake_cfg = if (static_llvm) null else findAndParseConfigH(b, config_h_path_option);
stage2: fix building self-hosted compiler with -Dstatic-llvm This supersedes c81ae52ee0b2e952f8ed9c5c6517af8182bb09c1
2020-12-29 17:52:53 +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
if (is_stage1) {
exe.addIncludeDir("src");
exe.addIncludeDir("deps/SoftFloat-3e/source/include");
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 18:27:39 +00:00
test_stage2.addIncludeDir("src");
test_stage2.addIncludeDir("deps/SoftFloat-3e/source/include");
fix wrong entrypoint, undefined package, and wrong build option
2020-12-05 05:24:04 +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");
Change defineCMacro to take separate name and value arugments Before this change, when one or more of name or value are not known at comptime, build.zig files must allocate and do the concatanation, which can be cumbersome, and also adds a redundant allocation when name and value are slices. The new version only does a single allocation directly in the builder's allocator to concatonate name and value. The origional behavior is available in defineCMacroRaw, for use in situations such as parseing c compiler arguments. Additionally, several places have been updated to use the new funtions.
2021-03-23 22:58:24 +00:00
exe.defineCMacro("ZIG_LINK_MODE", "Static");
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 18:27:39 +00:00
test_stage2.defineCMacro("ZIG_LINK_MODE", "Static");
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 = b.addStaticLibrary("softfloat", null);
softfloat.setBuildMode(.ReleaseFast);
softfloat.setTarget(target);
softfloat.addIncludeDir("deps/SoftFloat-3e-prebuilt");
softfloat.addIncludeDir("deps/SoftFloat-3e/source/8086");
softfloat.addIncludeDir("deps/SoftFloat-3e/source/include");
softfloat.addCSourceFiles(&softfloat_sources, &[_][]const u8{ "-std=c99", "-O3" });
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
softfloat.single_threaded = single_threaded;
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 18:27:39 +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
exe.linkLibrary(softfloat);
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 18:27:39 +00:00
test_stage2.linkLibrary(softfloat);
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: -lversion -luuid on windows and -DNDEBUG=1 for clang sources
2020-12-05 05:55:50 +00:00
exe.addCSourceFiles(&stage1_sources, &exe_cflags);
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
exe.addCSourceFiles(&optimized_c_sources, &[_][]const u8{ "-std=c99", "-O3" });
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 18:27:39 +00:00
test_stage2.addCSourceFiles(&stage1_sources, &exe_cflags);
test_stage2.addCSourceFiles(&optimized_c_sources, &[_][]const u8{ "-std=c99", "-O3" });
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
}
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 (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);
}
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
try addCmakeCfgOptionsToExe(b, cfg, exe, use_zig_libcxx);
try addCmakeCfgOptionsToExe(b, cfg, test_stage2, use_zig_libcxx);
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 {
// Here we are -Denable-llvm but no cmake integration.
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
try addStaticLlvmOptionsToExe(exe);
try addStaticLlvmOptionsToExe(test_stage2);
build: -lversion -luuid on windows and -DNDEBUG=1 for clang sources
2020-12-05 05:55:50 +00:00
}
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
}
if (link_libc) {
exe.linkLibC();
test_stage2.linkLibC();
}
stage2: -Dlog enables all logging, log scopes can be set at runtime Previously you had to recompile if you wanted to change the log scopes that get printed. Now, log scopes can be set at runtime, and -Dlog controls whether all logging is available at runtime. Purpose here is a nicer development experience. Most likely stage2 developers will always want -Dlog enabled and then pass --debug-log scopes when debugging particular issues.
2021-01-19 22:49:08 +00:00
const enable_logging = b.option(bool, "log", "Whether to enable logging") orelse false;
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
const opt_version_string = b.option([]const u8, "version-string", "Override Zig version string. Default is to find out with git.");
const version = if (opt_version_string) |version| version else v: {
tests: Use {s} instead of {} when formatting strings
2020-11-26 12:28:38 +00:00
const version_string = b.fmt("{d}.{d}.{d}", .{ zig_version.major, zig_version.minor, zig_version.patch });
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
var code: u8 = undefined;
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
const git_describe_untrimmed = b.execAllowFail(&[_][]const u8{
"git", "-C", b.build_root, "describe", "--match", "*.*.*", "--tags",
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
}, &code, .Ignore) catch {
break :v version_string;
};
Restore the reverted semantic versioning commits restore "Comply with semantic versioning pre-release format" restore "stage2: SemVer compliance for development builds" restore "Remove 'g' prefix from commit hash in Zig semver" This reverts commit d96d8639e592b4bb4b2e330c4bd7412256b297d2. This reverts commit e8810f579406673edad0c9780c9d990f3034717a. This reverts commit 9afe5859a3e428b259a306c36a860e4d82dbb4bb.
2021-01-02 04:01:51 +00:00
const git_describe = mem.trim(u8, git_describe_untrimmed, " \n\r");
switch (mem.count(u8, git_describe, "-")) {
0 => {
Release 0.8.0
2021-06-04 18:21:32 +00:00
// Tagged release version (e.g. 0.8.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.8.0
2021-06-04 18:21:32 +00:00
// Untagged development build (e.g. 0.8.0-684-gbbe2cca1a).
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 09:01:47 +00:00
var it = mem.split(u8, git_describe, "-");
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 18:15:32 +00:00
}
};
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
exe_options.addOption([: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
const semver = try std.SemanticVersion.parse(version);
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
exe_options.addOption(std.SemanticVersion, "semver", semver);
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
exe_options.addOption(bool, "enable_logging", enable_logging);
exe_options.addOption(bool, "enable_tracy", tracy != null);
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 18:15:32 +00: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 21:51:29 +00:00
// On mingw, we need to opt into windows 7+ to get some features required by tracy.
const tracy_c_flags: []const []const u8 = if (target.isWindows() and target.getAbi() == .gnu)
&[_][]const u8{ "-DTRACY_ENABLE=1", "-fno-sanitize=undefined", "-D_WIN32_WINNT=0x601" }
else
&[_][]const u8{ "-DTRACY_ENABLE=1", "-fno-sanitize=undefined" };
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
exe.addIncludeDir(tracy_path);
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
exe.addCSourceFile(client_cpp, tracy_c_flags);
stage2: building libunwind.a and put glibc shared objects on the elf linker line
2020-09-17 00:17:37 +00:00
if (!enable_llvm) {
exe.linkSystemLibraryName("c++");
}
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
exe.linkLibC();
Fix compiler builds with tracy on the mingw target
2021-09-16 21:51:29 +00:00
if (target.isWindows()) {
exe.linkSystemLibrary("dbghelp");
exe.linkSystemLibrary("ws2_32");
}
stage2: eliminate the "compiler id" concept Instead, append a "dirty suffix" to the version string when there are dirty git changes and use the version string as the compiler id. This avoids a dependency on the cache hash system, and saves time on first invocation of the compiler since it does not have to compute its compiler id. It also saves time by not having to check the cache for a saved compiler id.
2020-09-08 18:15:32 +00:00
}
convert compare-output tests to use zig build system
2017-04-19 05:13:15 +00:00
const test_filter = b.option([]const u8, "test-filter", "Skip tests that do not match filter");
significantly increase test coverage * add zig build option `-Dskip-libc` to skip tests that build libc (e.g. if you don't want to wait for musl to build) * add `-Denable-wine` option which uses wine to run cross compiled windows tests on non-windows hosts * add `-Denable-qemu` option which uses qemu to run cross compiled foreign architecture tests * add `-Denable-foreign-glibc=path` option which combined with `-Denable-qemu` enables running cross compiled tests that link against glibc. See https://github.com/ziglang/zig/wiki/Updating-libc#glibc for how to produce this directory. * the test matrix is done manually. release test builds are only enabled by default for the native target. this should save us some CI time, while still providing decent coverage of release builds. - add test coverage for `x86_64-linux-musl -lc` (building musl libc) - add test coverage for `x86_64-linux-gnu -lc` (building glibc) - add test coverage for `aarch64v8_5a-linux-none` - add test coverage for `aarch64v8_5a-linux-musl -lc` (building musl libc) - add test coverage for `aarch64v8_5a-linux-gnu -lc` (building glibc) - add test coverage for `arm-linux-none` - test coverage for `arm-linux-musleabihf -lc` (building musl libc) is disabled due to #3286 - test coverage for `arm-linux-gnueabihf -lc` (building glibc) is disabled due to #3287 - test coverage for `x86_64-windows-gnu -lc` (building mingw-w64) is disabled due to #3285 * enable qemu testing on the Linux CI job. There's not really a good reason to enable wine, since we have a Windows CI job as well. * remove the no longer needed `--build-file ../build.zig` from CI scripts * fix bug in glibc compilation where it wasn't properly reading the abi list txt files, resulting in "key not found" error. * std.build.Target gains: - isNetBSD - isLinux - osRequiresLibC - getArchPtrBitWidth - getExternalExecutor * zig build system gains support for enabling wine and enabling qemu. `artifact.enable_wine = true;`, `artifact.enable_qemu = true;`. This communicates that the system has these tools installed and the build system will use them to run tests. * zig build system gains support for overriding the dynamic linker of an executable artifact. * fix std.c.lseek prototype. makes behavior tests for arm-linux-musleabihf pass. * disable std lib tests that are failing on ARM. See #3288, #3289 * provide `std.os.off_t`. * disable some of the compiler_rt symbols for arm 32 bit. Fixes compiler_rt tests for arm 32 bit * add __stack_chk_guard when linking against glibc. Fixes std lib tests for aarch64-linux-gnu * workaround for "unable to inline function" using `@inlineCall`. Fixes compiler_rt tests for arm 32 bit.
2019-09-22 03:55:56 +00:00
const is_wine_enabled = b.option(bool, "enable-wine", "Use Wine to run cross compiled Windows tests") orelse false;
const is_qemu_enabled = b.option(bool, "enable-qemu", "Use QEMU to run cross compiled foreign architecture tests") orelse false;
Disable tests requiring Wasmtime be default; require -Denable-wasmtime flag otherwise
2020-05-13 06:08:16 +00:00
const is_wasmtime_enabled = b.option(bool, "enable-wasmtime", "Use Wasmtime to enable and run WASI libstd tests") orelse false;
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
const is_darling_enabled = b.option(bool, "enable-darling", "[Experimental] Use Darling to run cross compiled macOS tests") orelse false;
significantly increase test coverage * add zig build option `-Dskip-libc` to skip tests that build libc (e.g. if you don't want to wait for musl to build) * add `-Denable-wine` option which uses wine to run cross compiled windows tests on non-windows hosts * add `-Denable-qemu` option which uses qemu to run cross compiled foreign architecture tests * add `-Denable-foreign-glibc=path` option which combined with `-Denable-qemu` enables running cross compiled tests that link against glibc. See https://github.com/ziglang/zig/wiki/Updating-libc#glibc for how to produce this directory. * the test matrix is done manually. release test builds are only enabled by default for the native target. this should save us some CI time, while still providing decent coverage of release builds. - add test coverage for `x86_64-linux-musl -lc` (building musl libc) - add test coverage for `x86_64-linux-gnu -lc` (building glibc) - add test coverage for `aarch64v8_5a-linux-none` - add test coverage for `aarch64v8_5a-linux-musl -lc` (building musl libc) - add test coverage for `aarch64v8_5a-linux-gnu -lc` (building glibc) - add test coverage for `arm-linux-none` - test coverage for `arm-linux-musleabihf -lc` (building musl libc) is disabled due to #3286 - test coverage for `arm-linux-gnueabihf -lc` (building glibc) is disabled due to #3287 - test coverage for `x86_64-windows-gnu -lc` (building mingw-w64) is disabled due to #3285 * enable qemu testing on the Linux CI job. There's not really a good reason to enable wine, since we have a Windows CI job as well. * remove the no longer needed `--build-file ../build.zig` from CI scripts * fix bug in glibc compilation where it wasn't properly reading the abi list txt files, resulting in "key not found" error. * std.build.Target gains: - isNetBSD - isLinux - osRequiresLibC - getArchPtrBitWidth - getExternalExecutor * zig build system gains support for enabling wine and enabling qemu. `artifact.enable_wine = true;`, `artifact.enable_qemu = true;`. This communicates that the system has these tools installed and the build system will use them to run tests. * zig build system gains support for overriding the dynamic linker of an executable artifact. * fix std.c.lseek prototype. makes behavior tests for arm-linux-musleabihf pass. * disable std lib tests that are failing on ARM. See #3288, #3289 * provide `std.os.off_t`. * disable some of the compiler_rt symbols for arm 32 bit. Fixes compiler_rt tests for arm 32 bit * add __stack_chk_guard when linking against glibc. Fixes std lib tests for aarch64-linux-gnu * workaround for "unable to inline function" using `@inlineCall`. Fixes compiler_rt tests for arm 32 bit.
2019-09-22 03:55:56 +00:00
const glibc_multi_dir = b.option([]const u8, "enable-foreign-glibc", "Provide directory with glibc installations to run cross compiled tests that link glibc");
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
const test_stage2_options = b.addOptions();
test_stage2.addOptions("build_options", test_stage2_options);
test_stage2_options.addOption(bool, "enable_logging", enable_logging);
test_stage2_options.addOption(bool, "skip_non_native", skip_non_native);
test_stage2_options.addOption(bool, "skip_compile_errors", skip_compile_errors);
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 05:50:10 +00: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);
Rework build system `build_options` API (#9623) * rework `build_options` to integrate with the FileSource abstraction * support mapping as an arbitrarily named package * support mapping to multiple different artifacts * use hash of contents for options filename
2021-08-26 23:53:23 +00:00
test_stage2_options.addOption(bool, "enable_qemu", is_qemu_enabled);
test_stage2_options.addOption(bool, "enable_wine", is_wine_enabled);
test_stage2_options.addOption(bool, "enable_wasmtime", is_wasmtime_enabled);
test_stage2_options.addOption(u32, "mem_leak_frames", mem_leak_frames * 2);
test_stage2_options.addOption(bool, "enable_darling", is_darling_enabled);
test_stage2_options.addOption(?[]const u8, "glibc_multi_install_dir", glibc_multi_dir);
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 22:32:16 +00:00
self-hosted: first passing test * introduce std.atomic.Int * add src-self-hosted/test.zig which is tested by the main test suite - it fully utilizes the multithreaded async/await event loop so the tests should Go Fast * `stage2/bin/zig build-obj test.zig` is able to spit out an error if 2 exported functions collide * ability for `zig test` to accept `--object` and `--assembly` arguments * std.build: TestStep supports addLibPath and addObjectFile
2018-07-11 00:18:43 +00:00
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-15 23:20:43 +00: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 21:41:28 +00:00
toolchain_step.dependOn(test_stage2_step);
ci: drone: disable stage2 tests See #8545
2021-04-15 23:20:43 +00:00
}
self-hosted: first passing test * introduce std.atomic.Int * add src-self-hosted/test.zig which is tested by the main test suite - it fully utilizes the multithreaded async/await event loop so the tests should Go Fast * `stage2/bin/zig build-obj test.zig` is able to spit out an error if 2 exported functions collide * ability for `zig test` to accept `--object` and `--assembly` arguments * std.build: TestStep supports addLibPath and addObjectFile
2018-07-11 00:18:43 +00:00
ci: skip release-small tests to save time we keep hitting the limit on how long CI tests take to run.
2018-09-12 18:50:26 +00:00
var chosen_modes: [4]builtin.Mode = undefined;
var chosen_mode_index: usize = 0;
ci: drone disable debug test suite for aarch64 Temporary workaround for #8597 until upstream fix lands. - add `zig build -Dskip-debug` option - build a release-fast build.exe - disable test suite build modes { debug, release-small, release-safe } - enable passing test-* components - use parallel pipeline steps for tests
2021-04-24 20:39:26 +00:00
if (!skip_debug) {
chosen_modes[chosen_mode_index] = builtin.Mode.Debug;
chosen_mode_index += 1;
}
ci: skip release-small tests to save time we keep hitting the limit on how long CI tests take to run.
2018-09-12 18:50:26 +00:00
if (!skip_release_safe) {
chosen_modes[chosen_mode_index] = builtin.Mode.ReleaseSafe;
chosen_mode_index += 1;
}
if (!skip_release_fast) {
chosen_modes[chosen_mode_index] = builtin.Mode.ReleaseFast;
chosen_mode_index += 1;
}
if (!skip_release_small) {
chosen_modes[chosen_mode_index] = builtin.Mode.ReleaseSmall;
chosen_mode_index += 1;
}
const modes = chosen_modes[0..chosen_mode_index];
std.io: introduce buffered I/O and change API I started working on #465 and made some corresponding std.io API changes. New structs: * std.io.FileInStream * std.io.FileOutStream * std.io.BufferedOutStream * std.io.BufferedInStream Removed: * std.io.File.in_stream * std.io.File.out_stream Now instead of &file.out_stream or &file.in_stream to get access to the stream API for a file, you get it like this: var file_in_stream = io.FileInStream.init(&file); const in_stream = &file_in_stream.stream; var file_out_stream = io.FileOutStream.init(&file); const out_stream = &file_out_stream.stream; This is evidence that we might not need any OOP features - See #130.
2017-11-07 08:22:27 +00:00
add builder.addFmt API and use it to test stage1 zig fmt closes #1968
2019-02-26 23:10:40 +00:00
// run stage1 `zig fmt` on this build.zig file just to make sure it works
Azure CI: Test std.* and the rest separately On CI, we have been running into OOM issues when running the test suite on Windows for quite some time. Unfortunately, we are very close to having the same issues on Linux as well. Some additional comptime work immediately makes these builds fail as well. Add a new `test-toolchain` step, that tests everything except `std.*` and documentation. On CI, call `test-toolchain`, `test-std` and `docs` separately instead of the `test` big hammer that emcompasses all of them. Change the special case we made for Windows to the same code as other platforms. This is a stopgap measure that stage2 will eventually make useless. Until then, it gives us some headroom. Change `linux_script` by the way to only output the log of failing steps. This shrinks the Linux CI log from a bazilion lines down to something more humanely manageable.
2021-04-30 21:41:28 +00:00
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 09:03:44 +00: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 04:44:38 +00:00
"test/behavior.zig",
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
"behavior",
"Run the behavior tests",
modes,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00: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 09:03:44 +00:00
skip_non_native,
skip_libc,
is_wine_enabled,
is_qemu_enabled,
is_wasmtime_enabled,
is_darling_enabled,
glibc_multi_dir,
));
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 17:06:22 +00:00
true, // skip_single_threaded
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
skip_non_native,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
true, // skip_libc
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
is_wine_enabled,
is_qemu_enabled,
is_wasmtime_enabled,
is_darling_enabled,
glibc_multi_dir,
));
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 17:06:22 +00:00
true, // skip_single_threaded
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
skip_non_native,
Add a flag to build a single-threaded compiler, for debugging
2021-06-03 17:06:22 +00:00
true, // skip_libc
Add experimental Darling support for cross testing macOS * for cross testing stage2 tests, we use `darling shell` command since the path to the tested binary is relative to cwd * for the `zig test` command, we simply use `darling` since the path to the binary is absolute
2021-05-13 09:03:44 +00:00
is_wine_enabled,
is_qemu_enabled,
is_wasmtime_enabled,
is_darling_enabled,
glibc_multi_dir,
));
Azure CI: Test std.* and the rest separately On CI, we have been running into OOM issues when running the test suite on Windows for quite some time. Unfortunately, we are very close to having the same issues on Linux as well. Some additional comptime work immediately makes these builds fail as well. Add a new `test-toolchain` step, that tests everything except `std.*` and documentation. On CI, call `test-toolchain`, `test-std` and `docs` separately instead of the `test` big hammer that emcompasses all of them. Change the special case we made for Windows to the same code as other platforms. This is a stopgap measure that stage2 will eventually make useless. Until then, it gives us some headroom. Change `linux_script` by the way to only output the log of failing steps. This shrinks the Linux CI log from a bazilion lines down to something more humanely manageable.
2021-04-30 21:41:28 +00:00
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 08:04:54 +00: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 21:41:28 +00: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 06:10:51 +00: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 21:41:28 +00:00
toolchain_step.dependOn(tests.addRunTranslatedCTests(b, test_filter, target));
ci: aarch64-linux: disable run-translated-c tests See #8537
2021-04-15 06:10:51 +00:00
}
"generate .h files" feature is no longer supported in stage1
2020-03-20 22:33:36 +00:00
// tests for this feature are disabled until we have the self-hosted compiler available
Azure CI: Test std.* and the rest separately On CI, we have been running into OOM issues when running the test suite on Windows for quite some time. Unfortunately, we are very close to having the same issues on Linux as well. Some additional comptime work immediately makes these builds fail as well. Add a new `test-toolchain` step, that tests everything except `std.*` and documentation. On CI, call `test-toolchain`, `test-std` and `docs` separately instead of the `test` big hammer that emcompasses all of them. Change the special case we made for Windows to the same code as other platforms. This is a stopgap measure that stage2 will eventually make useless. Until then, it gives us some headroom. Change `linux_script` by the way to only output the log of failing steps. This shrinks the Linux CI log from a bazilion lines down to something more humanely manageable.
2021-04-30 21:41:28 +00:00
// 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 09:03:44 +00: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,
is_wine_enabled,
is_qemu_enabled,
is_wasmtime_enabled,
is_darling_enabled,
glibc_multi_dir,
);
Azure CI: Test std.* and the rest separately On CI, we have been running into OOM issues when running the test suite on Windows for quite some time. Unfortunately, we are very close to having the same issues on Linux as well. Some additional comptime work immediately makes these builds fail as well. Add a new `test-toolchain` step, that tests everything except `std.*` and documentation. On CI, call `test-toolchain`, `test-std` and `docs` separately instead of the `test` big hammer that emcompasses all of them. Change the special case we made for Windows to the same code as other platforms. This is a stopgap measure that stage2 will eventually make useless. Until then, it gives us some headroom. Change `linux_script` by the way to only output the log of failing steps. This shrinks the Linux CI log from a bazilion lines down to something more humanely manageable.
2021-04-30 21:41:28 +00:00
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 18:09:05 +00:00
test_step.dependOn(docs_step);
convert compare-output tests to use zig build system
2017-04-19 05:13:15 +00:00
}
self-hosted: link with LLVM
2017-12-12 04:34:59 +00:00
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
const exe_cflags = [_][]const u8{
"-std=c++14",
"-D__STDC_CONSTANT_MACROS",
"-D__STDC_FORMAT_MACROS",
"-D__STDC_LIMIT_MACROS",
"-D_GNU_SOURCE",
"-fvisibility-inlines-hidden",
"-fno-exceptions",
"-fno-rtti",
"-Werror=type-limits",
"-Wno-missing-braces",
"-Wno-comment",
};
fn addCmakeCfgOptionsToExe(
b: *Builder,
cfg: CMakeConfig,
exe: *std.build.LibExeObjStep,
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
use_zig_libcxx: bool,
stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`.
2021-01-03 15:48:52 +00:00
) !void {
exe.addObjectFile(fs.path.join(b.allocator, &[_][]const u8{
cfg.cmake_binary_dir,
"zigcpp",
b.fmt("{s}{s}{s}", .{ exe.target.libPrefix(), "zigcpp", exe.target.staticLibSuffix() }),
}) catch unreachable);
assert(cfg.lld_include_dir.len != 0);
exe.addIncludeDir(cfg.lld_include_dir);
addCMakeLibraryList(exe, cfg.clang_libraries);
addCMakeLibraryList(exe, cfg.lld_libraries);
addCMakeLibraryList(exe, cfg.llvm_libraries);
build.zig: support -Duse-zig-libcxx This supports the case when it is known that LLVM, Clang, LLD were built with Clang (or `zig c++`). This commit updates the Linux CI script to pass this since we build using a zig tarball.
2021-09-16 20:09:32 +00:00
if (use_zig_libcxx) {
exe.linkLibCpp();
} else {
const need_cpp_includes = true;
// 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);
}
}
fn addStaticLlvmOptionsToExe(
exe: *std.build.LibExeObjStep,
) !void {
// 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);
}
// 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 19:39:02 +00: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 {
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
});
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 09:01:47 +00:00
const path_unpadded = mem.tokenize(u8, path_padded, "\r\n").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| {
tests: Use {s} instead of {} when formatting strings
2020-11-26 12:28:38 +00:00
warn("{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 {
tests: Use {s} instead of {} when formatting strings
2020-11-26 12:28:38 +00:00
warn("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.
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 18:27:39 +00:00
//exe.addIncludeDir("/nix/store/fvf3qjqa5qpcjjkq37pb6ypnk1mzhf5h-gcc-9.3.0/lib/gcc/x86_64-unknown-linux-gnu/9.3.0/../../../../include/c++/9.3.0");
//exe.addIncludeDir("/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.addIncludeDir("/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 09:01:47 +00:00
var it = mem.tokenize(u8, list, ";");
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
while (it.next()) |lib| {
if (mem.startsWith(u8, lib, "-l")) {
exe.linkSystemLibrary(lib["-l".len..]);
} else {
exe.addObjectFile(lib);
}
}
}
const CMakeConfig = struct {
cmake_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 09:01:47 +00:00
var lines_it = mem.tokenize(u8, config_h_text, "\r\n");
restore the option to build with cmake restore cmake to be capable of figuring out the zig version restore config.h and config.zig. config.h is used to detect whether we should propagate cmake configuration information to build.zig; however it can be overridden with -Dstatic-llvm. fix not passing -DZIG_LINK_MODE with zig build. when using the cmake build path, build.zig no longer tries to call llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable. build.zig logic reworked and simplified.
2020-12-08 00:23:17 +00:00
while (lines_it.next()) |line| {
inline for (mappings) |mapping| {
if (mem.startsWith(u8, line, mapping.prefix)) {
Update all usages of mem.split/mem.tokenize for generic version
2021-08-06 09:01:47 +00:00
var it = mem.split(u8, line, "\"");
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 {
const duplicated = mem.dupe(b.allocator, u8, s) catch unreachable;
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",
"deps/SoftFloat-3e/source/8086/s_commonNaNToF128M.c",
"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",
"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",
"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",
"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",
"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",
"deps/SoftFloat-3e/source/f16_to_f128M.c",
"deps/SoftFloat-3e/source/f16_to_f64.c",
"deps/SoftFloat-3e/source/f32_to_f128M.c",
"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",
"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",
"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",
"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",
"deps/SoftFloat-3e/source/s_normRoundPackMToF128M.c",
"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",
"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",
"deps/SoftFloat-3e/source/softfloat_state.c",
"deps/SoftFloat-3e/source/ui32_to_f128M.c",
"deps/SoftFloat-3e/source/ui64_to_f128M.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 11:28:46 +00: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 00:33:16 +00:00
"src/zig_llvm-ar.cpp",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"src/zig_clang_driver.cpp",
"src/zig_clang_cc1_main.cpp",
"src/zig_clang_cc1as_main.cpp",
// https://github.com/ziglang/zig/issues/6363
"src/windows_sdk.cpp",
self-hosted: first passing test * introduce std.atomic.Int * add src-self-hosted/test.zig which is tested by the main test suite - it fully utilizes the multithreaded async/await event loop so the tests should Go Fast * `stage2/bin/zig build-obj test.zig` is able to spit out an error if 2 exported functions collide * ability for `zig test` to accept `--object` and `--assembly` arguments * std.build: TestStep supports addLibPath and addObjectFile
2018-07-11 00:18:43 +00:00
};
remove `zig BUILD_INFO` hack Rather than stuffing configuration information into the Zig binary, the build script reads it from config.h. This solves a problem for package maintainers and improves the use case of deterministic builds. closes #3758
2020-04-04 15:57:28 +00:00
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
const clang_libs = [_][]const u8{
"clangFrontendTool",
"clangCodeGen",
"clangFrontend",
"clangDriver",
"clangSerialization",
"clangSema",
"clangStaticAnalyzerFrontend",
"clangStaticAnalyzerCheckers",
"clangStaticAnalyzerCore",
"clangAnalysis",
"clangASTMatchers",
"clangAST",
"clangParse",
"clangSema",
"clangBasic",
"clangEdit",
"clangLex",
"clangARCMigrate",
"clangRewriteFrontend",
"clangRewrite",
"clangCrossTU",
"clangIndex",
"clangToolingCore",
};
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 17:58:53 +00:00
// `llvm-config` here because we are cross compiling. Also omit LLVMTableGen
// from these libs.
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
const llvm_libs = [_][]const u8{
"LLVMWindowsManifest",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMXRay",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMLibDriver",
"LLVMDlltoolDriver",
"LLVMCoverage",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMLineEditor",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMXCoreDisassembler",
"LLVMXCoreCodeGen",
"LLVMXCoreDesc",
"LLVMXCoreInfo",
"LLVMX86Disassembler",
"LLVMX86AsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMX86CodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMX86Desc",
"LLVMX86Info",
"LLVMWebAssemblyDisassembler",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMWebAssemblyAsmParser",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMWebAssemblyCodeGen",
"LLVMWebAssemblyDesc",
build.zig: update list of LLVM libs companion commit to 0f35a1f37ade9cf25707c41711b352174f1e2789 fixes compiling with a dev kit.
2021-10-02 19:40:07 +00:00
"LLVMWebAssemblyUtils",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMWebAssemblyInfo",
"LLVMSystemZDisassembler",
"LLVMSystemZAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMSystemZCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMSystemZDesc",
"LLVMSystemZInfo",
"LLVMSparcDisassembler",
"LLVMSparcAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMSparcCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMSparcDesc",
"LLVMSparcInfo",
"LLVMRISCVDisassembler",
"LLVMRISCVAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMRISCVCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMRISCVDesc",
"LLVMRISCVInfo",
"LLVMPowerPCDisassembler",
"LLVMPowerPCAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMPowerPCCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMPowerPCDesc",
"LLVMPowerPCInfo",
"LLVMNVPTXCodeGen",
"LLVMNVPTXDesc",
"LLVMNVPTXInfo",
"LLVMMSP430Disassembler",
"LLVMMSP430AsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMMSP430CodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMMSP430Desc",
"LLVMMSP430Info",
"LLVMMipsDisassembler",
"LLVMMipsAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMMipsCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMMipsDesc",
"LLVMMipsInfo",
"LLVMLanaiDisassembler",
"LLVMLanaiCodeGen",
"LLVMLanaiAsmParser",
"LLVMLanaiDesc",
"LLVMLanaiInfo",
"LLVMHexagonDisassembler",
"LLVMHexagonCodeGen",
"LLVMHexagonAsmParser",
"LLVMHexagonDesc",
"LLVMHexagonInfo",
"LLVMBPFDisassembler",
"LLVMBPFAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMBPFCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMBPFDesc",
"LLVMBPFInfo",
"LLVMAVRDisassembler",
"LLVMAVRAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMAVRCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAVRDesc",
"LLVMAVRInfo",
"LLVMARMDisassembler",
"LLVMARMAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMARMCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMARMDesc",
"LLVMARMUtils",
"LLVMARMInfo",
"LLVMAMDGPUDisassembler",
"LLVMAMDGPUAsmParser",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMAMDGPUCodeGen",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAMDGPUDesc",
"LLVMAMDGPUUtils",
"LLVMAMDGPUInfo",
"LLVMAArch64Disassembler",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMAArch64AsmParser",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAArch64CodeGen",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMAArch64Desc",
"LLVMAArch64Utils",
"LLVMAArch64Info",
"LLVMOrcJIT",
"LLVMMCJIT",
"LLVMJITLink",
"LLVMInterpreter",
"LLVMExecutionEngine",
"LLVMRuntimeDyld",
build.zig: update list of LLVM libs companion commit to 0f35a1f37ade9cf25707c41711b352174f1e2789 fixes compiling with a dev kit.
2021-10-02 19:40:07 +00:00
"LLVMOrcTargetProcess",
"LLVMOrcShared",
"LLVMDWP",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"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 17:43:39 +00:00
"LLVMCoroutines",
"LLVMObjCARCOpts",
"LLVMipo",
"LLVMVectorize",
"LLVMLinker",
"LLVMInstrumentation",
"LLVMFrontendOpenMP",
"LLVMFrontendOpenACC",
"LLVMExtensions",
"LLVMDWARFLinker",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMGlobalISel",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMMIRParser",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMAsmPrinter",
build.zig: update list of LLVM libs companion commit to 0f35a1f37ade9cf25707c41711b352174f1e2789 fixes compiling with a dev kit.
2021-10-02 19:40:07 +00: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 17:43:39 +00:00
"LLVMSelectionDAG",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMCodeGen",
build.zig: update llvm libs
2021-04-15 17:43:39 +00:00
"LLVMIRReader",
"LLVMAsmParser",
"LLVMInterfaceStub",
"LLVMFileCheck",
"LLVMFuzzMutate",
ability to build stage1 using only a zig tarball The main idea here is that there are now 2 ways to get a stage1 zig binary: * The cmake path. Requirements: cmake, system C++ compiler, system LLVM, LLD, Clang libraries, compiled by the system C++ compiler. * The zig path. Requirements: a zig installation, system LLVM, LLD, Clang libraries, compiled by the zig installation. Note that the former can be used to now take the latter path. Removed config.h.in and config.zig.in. The build.zig script no longer is coupled to the cmake script. cmake no longer tries to determine the zig version. A build with cmake will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to get reverted. `zig build` now accepts `-Dstage1` which will build the stage1 compiler, and put the stage2 backend behind a feature flag. build.zig is simplified to only support the use case of enabling LLVM support when the LLVM, LLD, and Clang libraries were built by zig. This part is probably sadly going to have to get reverted to make package maintainers happy. Zig build system addBuildOption supports a couple new types. The biggest reason to make this change is that the zig path is an attractive option for doing compiler development work on Windows. It allows people to work on the compiler without having MSVC installed, using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
2020-12-05 04:33:29 +00:00
"LLVMTarget",
"LLVMScalarOpts",
"LLVMInstCombine",
"LLVMAggressiveInstCombine",
"LLVMTransformUtils",
"LLVMBitWriter",
"LLVMAnalysis",
"LLVMProfileData",
"LLVMObject",
"LLVMTextAPI",
"LLVMMCParser",
"LLVMMC",
"LLVMDebugInfoCodeView",
build.zig: update llvm libs
2021-04-15 17:43:39 +00: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