-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move many settings from being per-Compilation to being per-Module #18160
Conversation
With that structure, how can i add a file that i can import with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of typos I noticed in documentation.
lib/std/Build/Module.zig
Outdated
pic: ?bool, | ||
red_zone: ?bool, | ||
/// Whether to omit the stack frame pointer. Frees up a register and makes it | ||
/// more more difficiult to obtain stack traces. Has target-dependent effects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// more more difficiult to obtain stack traces. Has target-dependent effects. | |
/// more difficult to obtain stack traces. Has target-dependent effects. |
lib/std/Build/Module.zig
Outdated
depending_steps: std.AutoArrayHashMapUnmanaged(*std.Build.Step.Compile, void), | ||
/// This could either be a generated file, in which case the module | ||
/// contains exactly one file, or it could be a path to the root source | ||
/// file of directory of files which constitute the module. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be intended.
/// file of directory of files which constitute the module. | |
/// file or directory of files which constitute the module. |
lib/std/Build/Module.zig
Outdated
pic: ?bool = null, | ||
red_zone: ?bool = null, | ||
/// Whether to omit the stack frame pointer. Frees up a register and makes it | ||
/// more more difficiult to obtain stack traces. Has target-dependent effects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// more more difficiult to obtain stack traces. Has target-dependent effects. | |
/// more difficult to obtain stack traces. Has target-dependent effects. |
if im not wrong you would do exe.root_module.addAnonymousImport("name", .{
.target = target,
.optimize = optimize,
.root_source_file = some_lazy_path,
}); |
Nice - I had tried a few times to make this change in the frontend, but it does make sense to first make the corresponding build system changes, since they're the biggest practical issue. I can't look through this in much detail currently (got a lot going on), but I'm glad it's been worked on. Make sure there's a check and error message for other modules depending on the main module, since that's a scenario the frontend can't currently encode! |
491cdb1
to
21ce1b5
Compare
Still works. Perhaps a convenience API could be added to make it more clear that it's allowed. |
2920061
to
a5cc086
Compare
11f86d4
to
e785d4f
Compare
e785d4f
to
7be2e85
Compare
cf7864c
to
c36c3e4
Compare
b7fd803
to
f81838c
Compare
0ca3db0
to
4c6a12d
Compare
ziglang/zig#18160 introduces a few breaking changes to the build APIs. This handles those differences where relevant, building with both, 0.11 and the latest master.
- VMM - Paging for x86_64 - Updated to zig master - Now exceptions halt the OS, to avoid double faults - Because of the removal of `main_mod_path` (see ziglang/zig#18160) the file with the entry point has to be directly on the module root path. To solve this, we now have a `src/main.zig` that does a `usingnamespace` with a `switch` for the appropiate `start.zig` file. As a benefit, some generic functions like `panic` or the `root.os` abstraction layer can be here. - HAL system, mainly to abstract `cpu.zig`
ziglang/zig#18160 changed module syntax. This change brings the documentation in line with these updates.
Part 1: Per-Module Settings in the Build System
This moves many settings from
std.Build.Step.Compile
and intostd.Build.Module
, and then makes them transitive.In other words, it adds support for exposing Zig modules in packages, which are configured in various ways, such as depending on other link objects, include paths, or even a different optimization mode.
Now, transitive dependencies will be included in the compilation, so you can, for example, make a Zig module depend on some C source code, and expose that Zig module in a package.
closes #14719
Part 2: Per-Module Settings in the Compiler
This branch also migrates many settings from being per-Compilation to being per-Module in the compiler itself. This required extensive changes to the interaction between the CLI as well as Compilation.
Before, the compiler frontend autogenerated only one
@import("builtin")
module for the entire compilation, however, this branch makes it honor the differences in modules, so that modules can be compiled with different optimization modes, code model, valgrind integration, or even target CPU feature set.Part 2A: Yak Shave: Linker Options
This ballooned into an enormous changeset because I decided that the
link.Options
struct should not be stored inlink.File
, and I wanted to make those fields be resolved and set directly inlink.File
(the base struct) or the ObjectFormat-specific structs (such as MachO, Elf, etc.).This change has been needed for a long time, so this pays off some tech debt. I hope it does not cause too many conflicts.
Merge Checklist
std.zig.CrossTarget
tostd.zig.Target.Query
std.Target
std.Build.ResolvedTarget
to avoid redundantly resolving target queries@import("builtin")
that can be different from the root module one.Add a test for mixing modules with different optimization modes into the same compilation.replace @setRuntimeSafety with @optimizeFor #978Make different optimization modes per function supported in the LLVM backendreplace @setRuntimeSafety with @optimizeFor #978put all the modules in a flat array to make them easier to iterateunimportant refactor, do it when there are fewer open PRsflatten link.File into LinkFile.zigunimportant refactor, do it when there are fewer open PRsrename bin_file to link_fileunimportant refactor, do it when there are fewer open PRsregression: aarch64-windows coff dwarf standalone testdisabled test: coff_dwarf standalone test #18427Upgrade Guide
modules can now be configured in more useful ways
Now, every
Compile
step has aroot_module
field which can be accessed directly.optimize_mode
,target
(CPU features),single_threaded
, and many more.It's now possible to make a module depend on the main module of a compilation.
Many of these fields were moved from
std.Build.Step.Compile
tostd.Build.Module
. Instead of setting the field of Compile, set it in the options passed to addExecutable, addStaticLibrary, etc., or, change it to set the field of a Compile step'sroot_module
.main_mod_path
is removedThere is no replacement. The root source file of a zig module determines the module's root directory - it is the root source file's direct parent. This was done to simplify Zig modules conceptually.
If your code depends on setting
main_mod_path
, here are some ways to transition to the new API:main_mod_path
.@import
.Removal of vcpkg integration
Instead of vcpkg, users are encouraged to use the Zig package manager to fulfill dependencies on Windows.
std.zig.CrossTarget
renamed tostd.Target.Query
Now there is a clear delineation using the concept of a target query and a fully resolved target. Here is some example code:
I left the types in there for clarity, but in practice it will probably look more like this:
Error Return Tracing in ReleaseSafe Optimization Mode
Before, error return tracing defaulted to on in ReleaseSafe mode. Now it defaults to off since it is a debugging feature rather than a safety feature. To obtain the previous behavior, one can pass
-ferror-tracing
(CLI) or pass.error_tracing = true,
toaddExecutable
and similar functions.Like many other settings, this can now be configured on a per-Module basis.
CLI
Old syntax:
--mod a:a,b=c:d --deps a,b=c
New syntax:
--dep a --dep b=c --mod a d
Note that
--mod
takes two parameters. It is the only CLI option that takes two parameters.All per-module settings on the CLI apply to the next
--mod
argument. Global settings are unaffected.Any
-I
args appearing after the final--mod
argument affect all modules.All C source files are now attached to a module, as demonstrated by this error message:
This is fixed by attaching the C source file to the module by putting it first:
If there is no
--mod
argument then zig infers one at the end, so this still works fine:--prominent-compile-errors
This was removed in 986a30e but it is now added again.
This reintroduced flag makes
zig build
behave the same as before this branch. Without this flag, the default behavior is now changed to display compilation errors inline with the rest of error messages and the build tree context.This behavior is essential for making sense of error logs from projects that have two or more steps emitting compilation errors which is why it is now the default.
As an example, before, you could see something like this:
which makes no goddamn sense at all. Now, it looks like this by default:
and you can get the nonsensical output if you pass
--prominent-compile-errors
.That paste above is only the first 3, but you can already see how the output is more discernible.