2020-09-04 04:23:00 +01:00
|
|
|
pub const have_llvm = true;
|
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
|
|
|
pub const version: [:0]const u8 = "0.0.0+zig0";
|
|
|
|
|
pub const semver: @import("std").SemanticVersion = .{
|
|
|
|
|
.major = 0,
|
|
|
|
|
.minor = 0,
|
|
|
|
|
.patch = 0,
|
|
|
|
|
.build = "zig0",
|
|
|
|
|
};
|
2020-08-18 01:06:23 +01:00
|
|
|
pub const log_scopes: []const []const u8 = &[_][]const u8{};
|
2020-09-04 04:23:00 +01:00
|
|
|
pub const zir_dumps: []const []const u8 = &[_][]const u8{};
|
2020-08-18 01:06:23 +01:00
|
|
|
pub const enable_tracy = false;
|
delete all stage1 c++ code not directly related to compiling stage2
Deleted 16,000+ lines of c++ code, including:
* an implementation of blake hashing
* the cache hash system
* compiler.cpp
* all the linking code, and everything having to do with building
glibc, musl, and mingw-w64
* much of the stage1 compiler internals got slimmed down since it
now assumes it is always outputting an object file.
More stuff:
* stage1 is now built with a different strategy: we have a tiny
zig0.cpp which is a slimmed down version of what stage1 main.cpp used
to be. Its only purpose is to build stage2 zig code into an object
file, which is then linked by the host build system (cmake) into
stage1. zig0.cpp uses the same C API that stage2 now has access to,
so that stage2 zig code can call into stage1 c++ code.
- stage1.h is
- stage2.h is
- stage1.zig is the main entry point for the Zig/C++
hybrid compiler. It has the functions exported from Zig, called
in C++, and bindings for the functions exported from C++, called
from Zig.
* removed the memory profiling instrumentation from stage1.
Abandon ship!
* Re-added the sections to the README about how to build stage2 and
stage3.
* stage2 now knows as a comptime boolean whether it is being compiled
as part of stage1 or as stage2.
- TODO use this flag to call into stage1 for compiling zig code.
* introduce -fdll-export-fns and -fno-dll-export-fns and clarify
its relationship to link_mode (static/dynamic)
* implement depending on LLVM to detect native target cpu features when
LLVM extensions are enabled and zig lacks CPU feature detection for
that target architecture.
* C importing is broken, will need some stage2 support to function
again.
2020-09-18 02:29:38 +01:00
|
|
|
pub const is_stage1 = true;
|
2020-12-02 21:51:22 +00:00
|
|
|
pub const skip_non_native = false;
|