I’m reading the release notes and I noted that in System Integration Help Section, the example uses --host-target and friends that were removed in std.Build: revert --host-target, --host-cpu, --host-dynamic-linker · ziglang/zig@22a97cd · GitHub.
Yes, the system integration section doesn’t look like it’s described in the release note.
System Integration Options:
--search-prefix [path] Add a path to look for binaries, libraries, headers
--sysroot [path] Set the system root directory (usually /)
--libc [file] Provide a file which specifies libc paths
--system [pkgdir] Disable package fetching; enable all integrations
-fsys=[name] Enable a system integration
-fno-sys=[name] Disable a system integration
I don’t get it how std_options work. If I want to disable https I just need to define const std_options like here and I don’t need to pass std_options anywhere else?
pub const std_options: std.Options = .{
.http_disable_tls = false,
};
Example usage of std_options Zig Documentation.
Also I can ommit : std.Options from std_options: std.Options?
What does “501(c)(3)” mean?
It’s an US IRS classification for tax-exempted, non-profit type of organization.
501(c)(3) description: Religious, Educational, Charitable, Scientific, Literary, Testing for Public Safety, to Foster National or International Amateur Sports Competition, or Prevention of Cruelty to Children or Animals Organizations.
Zig searches for a symbol named std_options in the root file (the file that includes the main function). It expects std_options to be of type std.Options. If the symbol is missing it is using default values.
It is used as:
const root = @import("root");
const options: Options = if (@hasDecl(root, "std_options")) root.std_options else .{};
if (options.http_disable_tls)
...
You don’t have to pass it elsewhere.
Yes, you can omit the type.
cool, thanx!
Yes.
As an example, std.log does:
const std = @import("std.zig");
const level = std.options.log_level;
See also
const root = @import("root");
/// Stdlib-wide options that can be overridden by the root file.
pub const options: Options = if (@hasDecl(root, "std_options")) root.std_options else .{};
in std.zig
Since @hasDecl only match the declaration name, you can omit the type.
However see Global Configuration for the reason why the Option type was added.
zls 0.12.0 pending
Not related directly to 0.12, but the zig master is incredibly fast for compilation, on the project I’m working on it went from 4/5 sec each compilation to just be almost instant it’s incredible
I assume and hope zig fmt also improved its speed … it was getting annoying to wait for its nvim integration on each save, walking into the multiple seconds per buffer format for just a few thousand LOC. Looking forward to trying out pulling my reference up to 0.12 from 0.12 dev!
Addendum: oh my, it isn’t zig fmt that’s deterring my nvim/zls/tree-sitter experience 
ISTM I’ll need to dive into nvim’s layers of “magic” to figure out why this is becoming unusable to work with, seems it’s not zig itself …
The first time you run zig fmt it will build the zig fmt subcommand which takes a few seconds. Then it should be instant after that.
You should try Helix while you are investigating the source of your issue, that’s what I use and it doesn’t have any problem formatting thousands of line on the spot as long as you have the zls binary somewhere on your path, you should be good to go directly
Well, I am using nvim with zls too, and there are zero issues. Only thing that’s funny is exactly this zig fmt thing when I save some piece of code after recompiling Zig.
For most people the zig fmt compilation isn’t a problem, but I am doing my programming on a Mac Book Pro from mid 2012 with Linux installed on it, so regular Zig compilation takes around 12 mins, LLVM around 3 hours and zig fmt around 30 secs…
I have one question regarding how the build system looks very low level. Are we going to get higher level primitives like “zig add package_name” to add a package and it’s required stuff automatically into the build.zig file? Or is that out of scope for the core language features and the community should build together abstractions on top of the existing lower level build system?
I don’t understand what you mean. To me, the build system feels high level. What would zig add package_name do?
My understanding is: When a package is added, its modules must be exposed to executables and libraries and be usable with @import("module-name") without touching build.zig.
probably he means central repository of packages and something like cargo add <package>