From 56b15d3f31ea2b2384de93f53c9e191167acafb4 Mon Sep 17 00:00:00 2001 From: ekusiadadus Date: Fri, 9 May 2025 20:16:21 +0900 Subject: [PATCH 1/8] feat: add ja-jp translation for why zig? --- content/ja-JP/learn/why_zig_rust_d_cpp.smd | 233 +++++++++------------ 1 file changed, 102 insertions(+), 131 deletions(-) diff --git a/content/ja-JP/learn/why_zig_rust_d_cpp.smd b/content/ja-JP/learn/why_zig_rust_d_cpp.smd index 00817f191..b228603ba 100644 --- a/content/ja-JP/learn/why_zig_rust_d_cpp.smd +++ b/content/ja-JP/learn/why_zig_rust_d_cpp.smd @@ -1,5 +1,5 @@ --- -.title = "Why Zig When There is Already C++, D, and Rust?", +.title = "すでにC++, D, Rustがあるのに、なぜZigなのか？", .author = "", .date = @date("2024-08-07:00:00:00"), .layout = "page.shtml", @@ -8,9 +8,10 @@ }, --- -# No hidden control flow +# 隠蔽された制御フローがない If Zig code doesn't look like it's jumping away to call a function, then it isn't. This means you can be sure that the following code calls only `foo()` and then `bar()`, and this is guaranteed without needing to know the types of anything: +Zigコードが関数を呼び出すためにジャンプしているように見えなければ、実際にジャンプしていません。つまり、以下のコードが`foo()`を呼び出し、その後`bar()`を呼び出すだけであることが確信でき、何の型もシル必要なく保証されます。 ```zig var a = b + c.d; @@ -18,141 +19,111 @@ foo(); bar(); ``` -Examples of hidden control flow: +隠蔽された制御フローの例: -* D has `@property` functions, which are methods that you call with what looks like field access, so in the above example, `c.d` might call a function. -* C++, D, and Rust have operator overloading, so the `+` operator might call a function. -* C++, D, and Go have throw/catch exceptions, so `foo()` might throw an exception, and prevent `bar()` from being called. (Of course, even in Zig `foo()` could deadlock and prevent `bar()` from being called, but that can happen in any Turing-complete language.) +* D には`@property`関数があり、これはフィールドアクセスのように見える関数を呼び出すメソッドです。上の例では、`c.d`が関数を呼び出す可能性があります。 +* C++, D, そしてRustには演算子オーバーロードがあるため、`+`演算子が関数を呼び出す可能性があります。 +* C++, D, そしてGoにはthrow/catch例外があるため、`foo()`が例外をスローし、`bar()`の呼び出しを防ぐ可能性があります。(もちろん、Zigでも`foo()`がデッドロックして`bar()`の呼び出しを防ぐ可能性がありますが、それはチューリング完全な言語ではどれでも起こり得ます。) The purpose of this design decision is to improve readability. +この設計決定の目的は、読みやすさを向上させることです。 -# No hidden allocations +# 隠蔽されたメモリ割り当てがない -Zig has a hands-off approach when it comes to heap allocation. There is no `new` keyword -or any other language feature that uses a heap allocator (e.g. string concatenation operator[1]). -The entire concept of the heap is managed by library and application code, not by the language. -Examples of hidden allocations: +Zigはヒープ割り当てに関して干渉しないアプローチをとっています。 +`new`キーワードやヒープアロケータを使用する他の言語機能（例：文字列連結演算子[1]）はありません。 +ヒープの概念全体は言語ではなく、ライブラリとアプリケーションコードによって管理されています。 -* Go's `defer` allocates memory to a function-local stack. In addition to being an unintuitive - way for this control flow to work, it can cause out-of-memory failures if you use - `defer` inside a loop. -* C++ coroutines allocate heap memory in order to call a coroutine. -* In Go, a function call can cause heap allocation because goroutines allocate small stacks - that get resized when the call stack gets deep enough. -* The main Rust standard library APIs panic on out of memory conditions, and the alternate - APIs that accept allocator parameters are an afterthought +隠蔽されたメモリ割り当ての例: + +* Goの`defer`は関数ローカルスタックにメモリを割り当てます。この制御フローの直感的でない動作に加えて、メモリ不足エラーを引き起こす可能性があります。 +* C++のコルーチンは、コルーチンを呼び出すためにヒープメモリを割り当てます。 +* Goでは、ゴルーチンが小さなスタックを割り当て、コールスタックが十分に深くなるとサイズが変更されるため、関数呼び出しがヒープ割り当てを引き起こす可能性があります。 +* Rustの標準ライブラリAPIは、メモリ不足条件でパニックを起こし、アロケーターパラメータを受け入れる代替APIは後付けです (see [rust-lang/rust#29802](https://github.com/rust-lang/rust/issues/29802)). -Nearly all garbage collected languages have hidden allocations strewn about, since the -garbage collector hides the evidence on the cleanup side. - -The main problem with hidden allocations is that it prevents the *reusability* of a -piece of code, unnecessarily limiting the number of environments that code would be -appropriate to be deployed to. Simply put, there are use cases where one must be able -to rely on control flow and function calls not to have the side-effect of memory allocation, -therefore a programming language can only serve these use cases if it can realistically -provide this guarantee. - -In Zig, there are standard library features that provide and work with heap allocators, -but those are optional standard library features, not built into the language itself. -If you never initialize a heap allocator, you can be confident your program will not heap allocate. - -Every standard library feature that needs to allocate heap memory accepts an `Allocator` parameter -in order to do it. This means that the Zig standard library supports freestanding targets. For -example `std.ArrayList` and `std.AutoHashMap` can be used for bare metal programming! - -Custom allocators make manual memory management a breeze. Zig has a debug allocator that -maintains memory safety in the face of use-after-free and double-free. It automatically -detects and prints stack traces of memory leaks. There is an arena allocator so that you can -bundle any number of allocations into one and free them all at once rather than manage -each allocation independently. Special-purpose allocators can be used to improve performance -or memory usage for any particular application's needs. - -[1]: Actually there is a string concatenation operator (generally an array concatenation operator), but it only works at compile time, so it still doesn't do any runtime heap allocation. - -# First-class support for no standard library - -As hinted above, Zig has an entirely optional standard library. Each std lib API only gets compiled -into your program if you use it. Zig has equal support for either linking against libc or -not linking against it. Zig is friendly to bare-metal and high-performance development. - -It's the best of both worlds; for example in Zig, WebAssembly programs can both use -the normal features of the standard library, and still result in the tiniest binaries when -compared to other programming languages that support compiling to WebAssembly. - -# A Portable Language for Libraries - -One of the holy grails of programming is code reuse. Sadly, in practice, we find ourselves re-inventing the wheel many times over again. Often it's justified. - - * If an application has real-time requirements, then any library that uses garbage collection or any other non-deterministic behavior is disqualified as a dependency. - * If a language makes it too easy to ignore errors, and thus hard to verify that a library correctly handles and bubbles up errors, it can be tempting to ignore the library and re-implement it, knowing that one handled all the relevant errors correctly. Zig is designed such that the laziest thing a programmer can do is handle errors correctly, and thus one can be reasonably confident that a library will properly bubble errors up. - * Currently it is pragmatically true that C is the most versatile and portable language. Any language that does not have the ability to interact with C code risks obscurity. Zig is attempting to become the new portable language for libraries by simultaneously making it straightforward to conform to the C ABI for external functions, and introducing safety and language design that prevents common bugs within the implementations. - -# A Package Manager and Build System for Existing Projects - -Zig is a toolchain in addition to a programming language. It comes with a -[build system and package manager](/learn/build-system/) that are useful even -in the context of a traditional C/C++ project. - -Not only can you write Zig code instead of C or C++ code, but you can use Zig -as a replacement for autotools, cmake, make, scons, ninja, etc. And on top of -this, it provides a package manager for native dependencies. This build system -is appropriate even if the entirety of a project's codebase is in C or C++. -For example, by -[porting ffmpeg to the zig build system](https://github.com/andrewrk/ffmpeg), -it becomes possible to compile ffmpeg on any supported system for any supported -system using only a [50 MiB download of zig](/download/). For open source -projects, this streamlined ability to build from source - and even -cross-compile - can be the difference between gaining or losing valuable -contributors. - -System package managers such as apt-get, pacman, homebrew, and others are -instrumental for end user experience, but they can be insufficient for the -needs of developers. A language-specific package manager can be the difference -between having no contributors and having many. For open source projects, the -difficulty of getting the project to build at all is a huge hurdle for -potential contributors. For C/C++ projects, having dependencies can be fatal, -especially on Windows, where there is no package manager. Even when just -building Zig itself, most potential contributors have a difficult time with the -LLVM dependency. Zig offers a way for projects to depend on native libraries -directly - without depending on the users' system package manager to have the -correct version available, and in a way that is practically guaranteed to -successfully build projects on the first try regardless of what system is being -used and independent of what platform is being targeted. - -**Other languages have package managers but they do not eliminate pesky system -dependencies like Zig does.** - -Zig can replace a project's build system with a reasonable language using -a declarative API for building projects, that also provides package management, -and thus the ability to actually depend on other C libraries. The ability to -have dependencies enables higher level abstractions, and thus the proliferation -of reusable high-level code. - -# Simplicity - -C++, Rust, and D have such a large number of features that they can be distracting from the actual meaning of the application you are working on. One finds oneself debugging one's knowledge of the programming language instead of debugging the application itself. - -Zig has no macros yet is still powerful enough to express complex programs in a -clear, non-repetitive way. Even Rust has macros with special cases like -`format!`, which is implemented in the compiler itself. Meanwhile in Zig, the -equivalent function is implemented in the standard library with no special case -code in the compiler. - -# Tooling - -Zig can be downloaded from [the downloads section](/download/). Zig provides -binary archives for Linux, Windows, and macOS. The following describes what you -get with one of these archives: - -* installed by downloading and extracting a single archive, no system configuration needed -* statically compiled so there are no runtime dependencies -* supports using LLVM for optimized release builds while using Zig's custom backends for faster compilation performance -* additionally supports a backend for outputting C code -* out of the box cross-compilation to most major platforms -* ships with source code for libc that will be dynamically compiled when needed for any supported platform -* includes build system with concurrency and caching -* compiles C and C++ code with libc support -* drop-in GCC/Clang command line compatibility with `zig cc` -* Windows resource compiler +ほとんど全てのガベレージコレクション言語には隠蔽されたメモリ割り当てが散在しています。 +これはガベージコレクタがクリーンアップ側の証拠を隠すからです。 + +隠蔽されたメモリ割り当ての主な問題は、コードの*再利用性*を妨げ、不必要にそのコードがデプロイされる環境の数を制限することです。 +シンプルに、制御フローや関数呼び出しがメモリ割り当ての副作用を持たないと確実に信頼できなければならないユースケースがあり、プログラミング言語はこの保証を実際に提供できる場合にのみ、これらのユースケースにサービスを提供できます。 + +Zigでは、標準ライブラリの機能がヒープアロケータを提供し、それを使用しますが、オプションの標準ライブラリ機能であり、言語自体に組み込まれていません。 +もしヒープアロケータを初期化しなければ、プログラムがヒープ割り当てを行わないことを確信できます。 + + +ヒープメモリを割り当てる必要がある標準ライブラリのすべての機能は、`Allocator`パラメータを受け入れます。 +これにより、Zig標準ライブラリはフリースタンディングターゲットをサポートします。 +例えば、`std.ArrayList`や`std.AutoHashMap`はベアメタルプログラミングに使用できます！ + + +カスタムアロケータにより、手動メモリ管理が簡単になります。 +Zigには、use-after-freeやdouble-freeに対してメモリ安全性を維持するデバッグアロケータがあります。 +メモリリークを自動的に検出し、スタックトレースを出力します。任意の数の割り当てを一つにまとめて、各割り当てを個別に管理するのではなく一度に全てを解放できるアリーナアロケータもあります。 +特殊目的のアロケータを使用して、特定のアプリケーションのニーズに合わせてパフォーマンスやメモリ使用量を改善できます。 + +[1]: 実際には文字列連結演算子（一般的には配列連結演算子）がありますが、コンパイル時にのみ機能するため、ランタイムのヒープ割り当ては行いません。 + +# 標準ライブラリを使用しない First-class サポート + +上記で示唆したように、Zigには完全にオプションの標準ライブラリがあります。 +各標準ライブラリAPIは、使用する場合にのみプログラムにコンパイルされます。 +Zigは、libcにリンクするかしないかにかかわらず、同等のサポートを提供します。 +Zigはベアメタルや高性能開発に適しています。 + +これは両方の世界の良いところを持っています。 +例えば、ZigではWebAssemblyプログラムが標準ライブラリの通常の機能を使用できると同時に、WebAssemblyへのコンパイルをサポートする他のプログラミング言語と比較して、最小のバイナリを生成することができます。 + +# ライブラリのためのポータブルな言語 + +プログラミングの聖杯の一つはコードの再利用です。残念ながら、実際には、私たちは何度も車輪を再発明しています。それには正当な理由があることが多いです。 + + * アプリケーションにリアルタイム要件がある場合、ガベージコレクションやその他の非決定的な動作を使用するライブラリは依存関係から除外されます。 + * 言語がエラーを無視することを容易にし、ライブラリが正しくエラーを処理して伝播させることを確認しにくい場合、そのライブラリを無視して再実装することが魅力的になります。自分自身がすべての関連エラーを正しく処理したことを知っているからです。Zigは、プログラマーが最も怠惰にできることがエラーを正しく処理することであるように設計されており、したがってライブラリが適切にエラーを伝播させることを合理的に確信できます。 + * 現在、実用的にはCが最も汎用的でポータブルな言語であることは事実です。Cコードと対話する能力を持たない言語は、知名度の低さをリスクとします。Zigは、外部関数のためにC ABIに準拠することを簡単にすると同時に、実装内の一般的なバグを防ぐ安全性と言語設計を導入することにより、新しいポータブルなライブラリ言語になることを目指しています。 + +# 既存プロジェクトのためのパッケージマネージャとビルドシステム + +Zigはプログラミング言語に加えてツールチェーンでもあります。 +従来のC/C++プロジェクトのコンテキストでも便利な[ビルドシステムとパッケージマネージャ](/learn/build-system/)が付属しています。 + + +CまたはC++コードの代わりにZigコードを書くことができるだけでなく、Zigをautotools、cmake、make、scons、ninjaなどの代替としてZigを使用することもできます。 +さらに、ネイティブ依存関係のためのパッケージマネージャも提供しています。このビルドシステムは、プロジェクトのコードベース全体がCまたはC++である場合でも適切です。 +このビルドシステムは、プロジェクトのコードベース全体がCまたはC++で書かれている場合でも適切です。例えば、[ffmpegをzigビルドシステムに移植する](https://github.com/andrewrk/ffmpeg)ことで、[わずか50MiBのzig](/download/)をダウンロードするだけで、ffmpegを任意のサポートされたシステムでコンパイルすることができます。オープンソースプロジェクトにとって、このソースからビルドするための簡素化された能力は、貴重なコントリビューターを獲得するか失うかの違いになる可能性があります。 + +apt-get, pacman, homebrew などのシステムパッケージマネージャはエンドユーザー体験に不可欠ですが、開発者のニーズには不十分な場合があります。 +言語固有のパッケージマネージャは、コントリビューターがいないか多くいるかの違いになる可能性があります。 +オープンソースプロジェクトにとって、プロジェクトをビルドすること自体の難しさは、潜在的なコントリビューターにとって大きな障害です。 +C/C++プロジェクトでは、依存関係が致命的になる可能性があります。特にWindowsでは、パッケージマネージャが存在しません。 +Zig自体をビルドする場合でも、ほとんどの潜在的なコントリビューターはLLVM依存関係に困難を感じています。 +Zigはプロジェクトがネイティブライブラリに直接依存する方法を提供します - ユーザーのシステムパッケージマネージャが正しいバージョンを利用可能にすることに依存せず、使用されているシステムや対象となるプラットフォームに関係なく、プロジェクトを最初の試みで確実にビルドする方法を提供します。 + +**他の言語にもパッケージマネージャはありますが、Zigのようにやっかいなシステム依存関係を排除するものはありません。** + +Zigはプロジェクトのビルドシステムを、プロジェクトをビルドするための宣言的APIを持つ合理的な言語に置き換え、パッケージ管理も提供し、他のCライブラリに依存する能力を提供します。依存関係を持つ能力により、より高いレベルの抽象化が可能になり、再利用可能な高レベルコードの増殖が促進されます。 + +# シンプル + +C++、Rust、Dには非常に多くの機能があり、実際に取り組んでいるアプリケーションの意味から気を散らすことがあります。アプリケーション自体をデバッグするのではなく、プログラミング言語に関する知識をデバッグしていることに気づくことがあります。 + +Zigにはマクロはありませんが、複雑なプログラムを明確で反復のない方法で表現するのに十分な強力さを持っています。 +Rust でさえ、コンパイラ自体に実装されている`format!`のような特別なケースを持つマクロがあります。 +一方、Zigでは、同等の機能はコンパイラに特殊なケースコードなしで標準ライブラリに実装されています。 + +# ツール + +Zigは[ダウンロードセクション](/download/)からダウンロードできます。ZigはLinux、Windows、macOS用のバイナリアーカイブを提供しています。 +以下はこれらのアーカイブの一つで得られるものについて説明しています。 + +* 単一のアーカイブをダウンロードして展開するだけでインストールでき、システム設定は必要ありません +* 静的にコンパイルされているため、ランタイム依存関係はありません +* 最適化されたリリースビルドにはLLVMを使用し、より高速なコンパイルパフォーマンスにはZigのカスタムバックエンドを使用することをサポートしています +* さらにCコードを出力するためのバックエンドをサポートしています +* ほとんどの主要なプラットフォームへのクロスコンパイルをすぐにサポートしています +* 必要に応じて任意のサポートされているプラットフォーム用に動的にコンパイルされるlibcのソースコードが付属しています +* 並列処理とキャッシングを備えたビルドシステムが含まれています +* libcサポート付きでCおよびC++コードをコンパイルします +* `zig cc`でGCC/Clangコマンドラインと互換性のあるドロップイン置き換えが可能です +* Windowsリソースコンパイラが含まれています From 5211c9d21e34c5120109d16cf46d2f79d38ea475 Mon Sep 17 00:00:00 2001 From: ekusiadadus Date: Fri, 9 May 2025 20:24:51 +0900 Subject: [PATCH 2/8] chore: update japanese index and documents --- content/ja-JP/learn/index.smd | 8 ++++---- content/ja-JP/learn/why_zig_rust_d_cpp.smd | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/content/ja-JP/learn/index.smd b/content/ja-JP/learn/index.smd index 1e8e50c2e..01961f42d 100644 --- a/content/ja-JP/learn/index.smd +++ b/content/ja-JP/learn/index.smd @@ -8,11 +8,11 @@ }, --- # [ドキュメント]($section.id('learn')) -This section lists resources useful to go from knowing nothing about Zig up -to understanding its philosophy. +This section lists resources useful to go from knowing nothing about Zig up +to understanding its philosophy. -## [Guides]($section.id('guides')) +## [ガイド]($section.id('guides')) This section is eventually going to be bundled with Zig's standard library documentation, but in the meantime you can browse it from here. @@ -35,7 +35,7 @@ Zigコードを書くのに便利なツールの一覧です。 ## 始めましょう Zigでプログラミングを始める準備ができたら、このガイドで環境を整えましょう。 -- [始めましょう](./getting-started) +- [始めましょう](./getting-started) ## オンライン学習リソース - [Introduction to Zig: a project-based book](https://github.com/pedropark99/zig-book) diff --git a/content/ja-JP/learn/why_zig_rust_d_cpp.smd b/content/ja-JP/learn/why_zig_rust_d_cpp.smd index b228603ba..91d677878 100644 --- a/content/ja-JP/learn/why_zig_rust_d_cpp.smd +++ b/content/ja-JP/learn/why_zig_rust_d_cpp.smd @@ -63,7 +63,7 @@ Zigには、use-after-freeやdouble-freeに対してメモリ安全性を維持 メモリリークを自動的に検出し、スタックトレースを出力します。任意の数の割り当てを一つにまとめて、各割り当てを個別に管理するのではなく一度に全てを解放できるアリーナアロケータもあります。 特殊目的のアロケータを使用して、特定のアプリケーションのニーズに合わせてパフォーマンスやメモリ使用量を改善できます。 -[1]: 実際には文字列連結演算子（一般的には配列連結演算子）がありますが、コンパイル時にのみ機能するため、ランタイムのヒープ割り当ては行いません。 +[1]: 実際には文字列連結演算子（一般的には配列連結演算子）がありますが、コンプタイムにのみ機能するため、ランタイムのヒープ割り当ては行いません。 # 標準ライブラリを使用しない First-class サポート From dfbc22e3fabc4f6fa51f0464352901de4448c5d0 Mon Sep 17 00:00:00 2001 From: ekusiadadus Date: Fri, 9 May 2025 20:26:50 +0900 Subject: [PATCH 3/8] fix: update japanese index for document "why zig" --- content/ja-JP/learn/index.smd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja-JP/learn/index.smd b/content/ja-JP/learn/index.smd index 01961f42d..ae309035e 100644 --- a/content/ja-JP/learn/index.smd +++ b/content/ja-JP/learn/index.smd @@ -24,7 +24,7 @@ Introduction to the Zig build system. - [詳細な概要](./overview/) ここでは、システム・プログラミングの観点から、Zigの詳細な機能概要を説明します。 -- [C++、D、Rustがあるのに、なぜZigなのか](./why_zig_rust_d_cpp/) +- [すでにC++, D, Rustがあるのに、なぜZigなのか？](./why_zig_rust_d_cpp/) C++、D、RustプログラマのためのZigの紹介です。 - [コード例](./samples/) Zigのコードがどのように見えるかを感じるためのスニペットのリストです。 From 5bd6b367856b4605598d4eaecec57d2e420d82fb Mon Sep 17 00:00:00 2001 From: ekusiadadus Date: Fri, 9 May 2025 20:29:04 +0900 Subject: [PATCH 4/8] chore: remove original english content from ja-jp doc --- content/ja-JP/learn/why_zig_rust_d_cpp.smd | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja-JP/learn/why_zig_rust_d_cpp.smd b/content/ja-JP/learn/why_zig_rust_d_cpp.smd index 91d677878..71867e3dd 100644 --- a/content/ja-JP/learn/why_zig_rust_d_cpp.smd +++ b/content/ja-JP/learn/why_zig_rust_d_cpp.smd @@ -10,7 +10,6 @@ # 隠蔽された制御フローがない -If Zig code doesn't look like it's jumping away to call a function, then it isn't. This means you can be sure that the following code calls only `foo()` and then `bar()`, and this is guaranteed without needing to know the types of anything: Zigコードが関数を呼び出すためにジャンプしているように見えなければ、実際にジャンプしていません。つまり、以下のコードが`foo()`を呼び出し、その後`bar()`を呼び出すだけであることが確信でき、何の型もシル必要なく保証されます。 ```zig From 5d545ad6431e687c36425507e53b6eef049b178e Mon Sep 17 00:00:00 2001 From: ekusiadadus Date: Sat, 10 May 2025 01:07:36 +0900 Subject: [PATCH 5/8] feat: add japanese translation for build-system --- content/ja-JP/learn/build-system.smd | 302 +++++++++++---------------- 1 file changed, 125 insertions(+), 177 deletions(-) diff --git a/content/ja-JP/learn/build-system.smd b/content/ja-JP/learn/build-system.smd index 80f74820d..9a0b88141 100644 --- a/content/ja-JP/learn/build-system.smd +++ b/content/ja-JP/learn/build-system.smd @@ -1,54 +1,49 @@ --- -.title = "Zig Build System", +.title = "Zig ビルドシステム", .author = "", .date = @date("2024-08-07:00:00:00"), .layout = "page.shtml", .custom = { - "mobile_menu_title": "Zig Build System", + "mobile_menu_title": "Zig ビルドシステム", "toc": true, }, --- -# [When to bust out the Zig Build System?]($heading.id('build-system')) +# [Zigビルドシステムを使うべきときは？]($heading.id('build-system')) -The fundamental commands `zig build-exe`, `zig build-lib`, `zig build-obj`, and -`zig test` are often sufficient. However, sometimes a project needs another -layer of abstraction to manage the complexity of building from source. +基本的なコマンド `zig build-exe`、`zig build-lib`、`zig build-obj`、および `zig test` が十分な場合が多いです。 +しかし、時にはプロジェクトがソースからビルドするための複雑さを管理するために別の抽象化レイヤーが必要な場合もあります。 -For example, perhaps one of these situations applies: +たとえば、以下のような状況が当てはまるかもしれません: -- The command line becomes too long and unwieldly, and you want some place to - write it down. -- You want to build many things, or the build process contains many steps. -- You want to take advantage of concurrency and caching to reduce build time. -- You want to expose configuration options for the project. -- The build process is different depending on the target system and other options. -- You have dependencies on other projects. -- You want to avoid an unnecessary dependency on cmake, make, shell, msvc, - python, etc., making the project accessible to more contributors. -- You want to provide a package to be consumed by third parties. -- You want to provide a standardized way for tools such as IDEs to semantically understand - how to build the project. +- コマンドラインが長くて扱いにくくなり、それを書き留める場所が欲しい。 +- 多くのものをビルドしたい、またはビルドプロセスに多くのステップが含まれている。 +- 並行処理とキャッシングを活用してビルド時間を短縮したい。 +- プロジェクトの設定オプションを公開したい。 +- ビルドプロセスがターゲットシステムや他のオプションによって異なる。 +- 他のプロジェクトへの依存関係がある。 +- cmake、make、シェル、msvc、pythonなどへの不必要な依存を避け、より多くの貢献者にプロジェクトをアクセスしやすくしたい。 +- サードパーティが利用できるパッケージを提供したい。 +- IDEなどのツールがプロジェクトのビルド方法を意味的に理解するための標準化された方法を提供したい。 -If any of these apply, the project will benefit from using the Zig Build System. +これらのいずれかに当てはまる場合、プロジェクトはZigビルドシステムを使用することで恩恵を受けるでしょう。 -# [Getting Started]($heading.id('getting-started')) -## [Simple Executable]($heading.id('simple')) -This build script creates an executable from a Zig file that contains a public main function definition. +# [はじめに]($heading.id('getting-started')) +## [シンプルな実行ファイル]($heading.id('simple')) +このビルドスクリプトは、パブリックなmain関数定義を含むZigファイルから実行ファイルを作成します。 []($code.language('=html').buildAsset("build-system/1-simple-executable/hello.zig")) []($code.language('=html').buildAsset("build-system/1-simple-executable/build.zig")) -## [Installing Build Artifacts]($heading.id('installing-artifacts')) +## [ビルド成果物のインストール]($heading.id('installing-artifacts')) -The Zig build system, like most build systems, is based on modeling the project as a directed acyclic graph (DAG) of steps, which are independently and concurrently run. +Zigビルドシステムは、ほとんどのビルドシステムと同様に、個別に並行して実行されるステップの有向非巡回グラフ（DAG）としてプロジェクトをモデル化することに基づいています。 -By default, the main step in the graph is the **Install** step, whose purpose -is to copy build artifacts into their final resting place. The Install step -starts with no dependencies, and therefore nothing will happen when `zig build` -is run. A project's build script must add to the set of things to install, which -is what the `installArtifact` function call does above. -**Output** +デフォルトでは、グラフの主要なステップは**インストール**ステップであり、その目的はビルド成果物を最終的な置き場所にコピーすることです。 +インストールステップは最初は依存関係がなく、したがって `zig build` を実行しても何も起こりません。 +プロジェクトのビルドスクリプトはインストールするもののセットに追加する必要があり、それが上記の `installArtifact` 関数呼び出しの役割です。 + +**出力** ``` ├── build.zig ├── hello.zig @@ -58,63 +53,57 @@ is what the `installArtifact` function call does above. └── hello ``` -There are two generated directories in this output: `.zig-cache` and `zig-out`. The first one contains files that will make subsequent builds faster, but these files are not intended to be checked into source-control and this directory can be completely deleted at any time with no consequences. +この出力には2つの生成されたディレクトリがあります: `.zig-cache` と `zig-out`です。 +最初のものは後続のビルドを高速化するファイルを含んでいますが、これらのファイルはソース管理することを意図しておらず、このディレクトリはいつでも完全に削除しても問題ありません。 -The second one, `zig-out`, is an "installation prefix". This maps to the standard file system hierarchy concept. This directory is not chosen by the project, but by the user of `zig build` with the `--prefix` flag (`-p` for short). +2つ目の `zig-out` は「インストールプレフィックス」です。これは標準的なファイルシステム階層の概念にマッピングされます。 +このディレクトリはプロジェクトによって選択されるのではなく、`--prefix`フラグ（短縮形は `-p`）を使用して `zig build` のユーザーによって選択されます。 -You, as the project maintainer, pick what gets put in this directory, but the user chooses where to install it in their system. The build script cannot hardcode output paths because this would break caching, concurrency, and composability, as well as annoy the final user. +プロジェクトメンテナとして、あなたはこのディレクトリに何を配置するかを決めますが、ユーザーはそれをシステムのどこにインストールするかを選びます。 +ビルドスクリプトは出力パスをハードコーディングすることはできません。なぜなら、これがキャッシング、並行性、組み合わせ可能性を破壊し、最終ユーザーを困らせることになるからです。 -## [Adding a Convenience Step for Running the Application]($heading.id('run-step')) +## [アプリケーション実行のための便利なステップの追加]($heading.id('run-step')) -It is common to add a **Run** step to provide a way to run one's main application directly -from the build command. +ビルドコマンドから直接メインアプリケーションを実行する方法を提供するために、**実行**ステップを追加することが一般的です。 []($code.language('=html').buildAsset("build-system/convenience-run-step/hello.zig")) []($code.language('=html').buildAsset("build-system/convenience-run-step/build.zig")) -# [The Basics]($heading.id('basics')) +# [基本]($heading.id('basics')) -## [User-Provided Options]($heading.id('user-options')) +## [ユーザー提供オプション](#user-provided-options) -Use `b.option` to make the build script configurable to end users as well as -other projects that depend on the project as a package. +`b.option`を使用して、エンドユーザーやパッケージとしてプロジェクトに依存する他のプロジェクトに対して、ビルドスクリプトを設定可能にします。 []($code.language('=html').buildAsset("build-system/2-user-provided-options/build.zig")) []($code.language('=html').buildAsset("build-system/2-user-provided-options/example.zig")) -Please direct your attention to these lines: +以下の行に注目してください: ``` Project-Specific Options: -Dwindows=[bool] Target Microsoft Windows ``` +ヘルプメニューのこの部分は、`build.zig`ロジックの実行に基づいて自動生成されます。 -This part of the help menu is auto-generated based on running the `build.zig` logic. Users -can discover configuration options of the build script this way. - -## [Standard Configuration Options]($heading.id('standard-options')) +## [標準設定オプション]($heading.id('standard-options')) -Previously, we used a boolean flag to indicate building for Windows. However, we can do -better. +以前は、Windowsをビルド対象とすることを示すためにブール値フラグを使用していました。しかし、より良い方法があります。 -Most projects want to provide the ability to change the target and optimization settings. -In order to encourage standard naming conventions for these options, Zig provides the -helper functions, `standardTargetOptions` and `standardOptimizeOption`. +ほとんどのプロジェクトはターゲットと最適化設定を変更する機能を提供したいと考えています。 +これらのオプションの標準的な命名規則を推奨するために、Zigは`standardTargetOptions`と`standardOptimizeOption`というヘルパー関数を提供しています。 -Standard target options allows the person running `zig build` to choose what -target to build for. By default, any target is allowed, and no choice means to -target the host system. Other options for restricting supported target set are -available. +標準ターゲットオプションにより、`zig build`を実行する人はビルド対象を選択することが出来ます。 +デフォルトでは、どのターゲットも許可され、選択がない場合はホストシステムをターゲットにします。 +サポートされるターゲットセットを制限するための他のオプションも利用できます。 -Standard optimization options allow the person running `zig build` to select -between `Debug`, `ReleaseSafe`, `ReleaseFast`, and `ReleaseSmall`. By default -none of the release options are considered the preferable choice by the build -script, and the user must make a decision in order to create a release build. +標準最適化オプションにより、`zig build`を実行する人は、`Debug`、`ReleaseSafe`、`ReleaseFast`、および `ReleaseSmall`の間で選択することができます。 +デフォルトでは、ビルドスクリプトはどのリリースオプションも優先的な選択とみなさず、ユーザーはリリースビルドを作成するためにユーザーが決定を下す必要があります。 []($code.language('=html').buildAsset("build-system/3-standard-config-options/hello.zig")) []($code.language('=html').buildAsset("build-system/3-standard-config-options/build.zig")) -Now, our `--help` menu contains more items: +`--help`メニューには、より多くの項目が含まれています: ``` Project-Specific Options: @@ -128,11 +117,10 @@ Project-Specific Options: ReleaseSmall ``` -It is entirely possible to create these options via `b.option` directly, but this -API provides a commonly used naming convention for these frequently used settings. +`b.option`で直接これらのオプションを作成することも完全に可能ですが、このAPIはこれらの頻繁に使用される設定のために一般的に使用される命名規則を提供します。 -In our terminal output, observe that we passed `-Dtarget=x86_64-windows -Doptimize=ReleaseSmall`. -Compared to the first example, now we see different files in the installation prefix: +ターミナル出力では、`-Dtarget=x86_64-windows -Doptimize=ReleaseSmall`を渡したことがわかります。 +最初の例と比較して、インストールプレフィックスに異なるファイルが表示されます: ``` zig-out/ @@ -140,29 +128,25 @@ zig-out/ └── hello.exe ``` -## [Options for Conditional Compilation]($heading.id('conditional-compilation')) +## [条件付きコンパイルのためのオプション]($heading.id('conditional-compilation')) -To pass options from the build script and into the project's Zig code, use -the `Options` step. +ビルドスクリプトからプロジェクトのZigコードにオプションを渡すには、`Options`ステップを使用します。 []($code.language('=html').buildAsset("build-system/conditional-compilation/app.zig")) []($code.language('=html').buildAsset("build-system/conditional-compilation/build.zig")) -In this example, the data provided by `@import("config")` is comptime-known, -preventing the `@compileError` from triggering. If we had passed `-Dversion=0.2.3` -or omitted the option, then we would have seen the compilation of `app.zig` fail with -the "too old" error. +この例では、`@import("config")`によって提供されるデータはコンパイル時に既知であり、`@compileError`の発動を防ぎます。 +もし`-Dversion=0.2.3`を渡したり、オプションを省略した場合、`app.zig`のコンパイルが「too old」というエラーで失敗します。 -## [Static Library]($heading.id('static-library')) +## [静的ライブラリ]($heading.id('static-library')) -This build script creates a static library from Zig code, and then also an -executable from other Zig code that consumes it. +このビルドスクリプトはZigコードから静的ライブラリを生成し、さらにそれらを利用する他のZigコードから実行ファイルも生成します。 []($code.language('=html').buildAsset("build-system/simple-static-library/fizzbuzz.zig")) []($code.language('=html').buildAsset("build-system/simple-static-library/demo.zig")) []($code.language('=html').buildAsset("build-system/simple-static-library/build.zig")) -In this case, only the static library ends up being installed: +この場合、静的ライブラリのみがインストールされます: ``` zig-out/ @@ -170,8 +154,8 @@ zig-out/ └── libfizzbuzz.a ``` -However, if you look closely, the build script contains an option to also install the demo. -If we additionally pass `-Denable-demo`, then we see this in the installation prefix: +しかしよく見るとビルドスクリプトはデモもインストールするオプションを含んでいます。 +さらに `-Denable-demo` を渡すと、インストールプレフィックスに以下のように表示されます: ``` zig-out/ @@ -181,19 +165,16 @@ zig-out/ └── libfizzbuzz.a ``` -Note that despite the unconditional call to `addExecutable`, the build system in fact -does not waste any time building the `demo` executable unless it is requested -with `-Denable-demo`, because the build system is based on a Directed Acyclic -Graph with dependency edges. +`addExecutable`への無条件の呼び出しにも関わらず、`-Denable-demo` で要求されない限り、ビルドシステムは実際には`demo`実行可能ファイルをビルドするのに時間を無駄にしません。 +これはビルドシステムが依存関係エッジをもつ有向非巡回グラフに基づいているからです。 -## [Dynamic Library]($heading.id('dynamic-library')) +## [動的ライブラリ]($heading.id('dynamic-library')) -Here we keep all the files the same from the [Static Library](#static-library) example, except -the `build.zig` file is changed. +ここでは、[静的ライブラリ](#static-library)の例からすべてのファイルを同じままにしておきますが、`build.zig`ファイルを変更します。 []($code.language('=html').buildAsset("build-system/dynamic-library/build.zig")) -**Output** +**出力** ``` zig-out └── lib @@ -202,43 +183,32 @@ zig-out └── libfizzbuzz.so.1.2.3 ``` -As in the static library example, to make an executable link against it, use code like this: +静的ライブラリの例と同様に、実行ファイルがそれにリンクするにはこのようなコードを使用します: ```zig exe.linkLibrary(libfizzbuzz); ``` -## [Testing]($heading.id('testing')) +## [テスト]($heading.id('testing')) + +個々のファイルは `zig test foo.zig` で直接テストできますが、より複雑なユースケースはビルドスクリプトを通じてテストを調整することで解決できます。 -Individual files can be tested directly with `zig test foo.zig`, however, more -complex use cases can be solved by orchestrating testing via the build script. +ビルドスクリプトを使用する場合、ユニットテストはビルドグラフの2つの異なるステップ、**コンパイル**ステップと**実行**ステップに分けられます。 +これらの2つのステップ間に依存関係エッジを確立する `addRunArtifact` の呼び出さない限り、ユニットテストは実行されません。 -When using the build script, unit tests are broken into two different steps in -the build graph, the **Compile** step and the **Run** step. Without a call to -`addRunArtifact`, which establishes a dependency edge between these two steps, -the unit tests will not be executed. +コンパイルステップは、例えば [システムライブラリにリンクする](#linking-to-system-libraries)、ターゲットオプションを設定する、または追加のコンパイルユニットを追加するなど、実行可能ファイル、ライブラリ、またはオブジェクトファイルと同様に構成できます。 -The Compile step can be configured the same as any executable, library, or -object file, for example by [linking against system libraries](#linking-to-system-libraries), -setting target options, or adding additional compilation units. +実行ステップは、任意の実行ステップと同じように構成できます。例えば、ホストがバイナリを実行できない場合に実行をスキップするなどです。 -The Run step can be configured the same as any Run step, for example by -skipping execution when the host is not capable of executing the binary. +ビルドシステムを使用してユニットテストを実行する場合、ビルドランナーとテストランナーは複数のユニットテストスイートを並行して実行し、それらの出力が混ざり合うことなく意味のある方法でテスト失敗を報告するために、*stdin*と*stdout*を介して通信します。 +これらは [ユニットテストで標準出力に書き込むことが問題となる](https://github.com/ziglang/zig/issues/15091)理由の1つです。- この通信チャネルに干渉するためです。 +一方で、このメカニズムは今後の機能、つまり[ユニットテストがパニックを期待する能力](https://github.com/ziglang/zig/issues/1356)を可能にします。 -When using the build system to run unit tests, the build runner and the test -runner communicate via *stdin* and *stdout* in order to run multiple unit test -suites concurrently, and report test failures in a meaningful way without -having their output jumbled together. This is one reason why -[writing to standard out in unit tests is problematic](https://github.com/ziglang/zig/issues/15091) - -it will interfere with this communication channel. On the flip side, this -mechanism will enable an upcoming feature, which is is the -[ability for a unit test to expect a panic](https://github.com/ziglang/zig/issues/1356). []($code.language('=html').buildAsset("build-system/unit-testing/main.zig")) []($code.language('=html').buildAsset("build-system/unit-testing/build.zig")) -In this case it might be a nice adjustment to enable `skip_foreign_checks` for -the unit tests: +この場合`skip_foreign_checks`をユニットテストに対して有効にするのは良い調整かもしれません: ```diff @@ -23,6 +23,7 @@ @@ -253,47 +223,36 @@ the unit tests: []($code.language('=html').buildAsset("build-system/unit-testing-skip-foreign/build.zig")) -## [Linking to System Libraries]($heading.id('linking-to-system-libraries')) +## [システムライブラリへのリンク]($heading.id('linking-to-system-libraries')) -For satisfying library dependencies, there are two choices: +ライブラリ依存関係を満たすには、2つの選択肢があります: -1. Provide these libraries via the Zig Build System - (see Package Management and [Static Library](#static-library)). -2. Use the files provided by the host system. +1. Zigビルドシステムを通じてこれらのライブラリを提供する + (パッケージ管理と[静的ライブラリ](#static-library)を参照)。 +2. ホストシステムが提供するファイルを使用する。 -For the use case of upstream project maintainers, obtaining these libraries via -the Zig Build System provides the least friction and puts the configuration -power in the hands of those maintainers. Everyone who builds this way will have -reproducible, consistent results as each other, and it will work on every -operating system and even support cross-compilation. Furthermore, it allows the -project to decide with perfect precision the exact versions of its entire -dependency tree it wishes to build against. This is expected to be the -generally preferred way to depend on external libraries. +上流プロジェクトメンテナのユーズケースでは、Zigビルドシステムを通じてこれらのライブラリを取得することで、摩擦が最小限に抑えられ、設定の力をそれらのメンテナの手に委ねることが出来ます。 +この方法でビルドする全ての人は互いに再現可能で一貫した結果を得ることができ、あらゆるオペレーティングシステムで機能し、さらにクロスコンパイルもサポートします。 +さらに、プロジェクトが依存関係ツリー全体の正確なバージョンを完璧な精度で決定することも可能です。これが一般的に好まれる外部ライブラリへの依存方法と予想されます。 -However, for the use case of packaging software into repositories such as -Debian, Homebrew, or Nix, it is mandatory to link against system libraries. So, -build scripts must -[detect the mode](https://github.com/ziglang/zig/issues/14281) and configure accordingly. +しかし、Debian, Homebrew, Nixなどのリポジトリにソフトウェアをパッケージするユースケースでは、システムライブラリにリンクすることが必須です。 +そのためビルドスクリプトは、[モードを検出](https://github.com/ziglang/zig/issues/14281)してそれに応じて構成する必要があります。 []($code.language('=html').buildAsset("build-system/system-libraries/build.zig")) -Users of `zig build` may use `--search-prefix` to provide additional -directories that are considered "system directories" for the purposes of finding -static and dynamic libraries. +`zig build`のユーザーは、`--search-prefix`を使用して、静的および動的ライブラリを見つけるための「システムディレクトリ」と見なされる追加のディレクトリを提供するために`--search-prefix`を使用できます。 -# [Generating Files]($heading.id('generating-files')) +# [ファイルの生成]($heading.id('generating-files')) -## [Running System Tools]($heading.id('system-tools')) -This version of hello world expects to find a `word.txt` file in the same path, -and we want to use a system tool to generate it starting from a JSON file. +## [システムツールの実行]($heading.id('system-tools')) -Be aware that system dependencies will make your project harder to build for your -users. This build script depends on `jq`, for example, which is not present by -default in most Linux distributions and which might be an unfamiliar tool for -Windows users. +このバージョンのhello worldは、同じパスに `word.txt` ファイルがあることを期待しており、JSONファイルから生成するためにシステムツールを使用して生成したいと考えています。 + +システム依存関係はプロジェクトのビルドをユーザーにとって難しくすることに注意してください。 +例えば、このビルドスクリプトは `jq` に依存していますが、これはほとんどのLinuxディストリビューションにデフォルトでは存在せず、Windowsユーザーには馴染みのないツールかもしれません。 + +次のセクションでは、`jq`をソースツリーに含まれるZigツールに置き換えます。これが推奨されるアプローチです。 -The next section will replace `jq` with a Zig tool included in the source tree, -which is the preferred approach. **`words.json`** ```json @@ -307,7 +266,7 @@ which is the preferred approach. []($code.language('=html').buildAsset("build-system/10.5-system-tool/src/main.zig")) []($code.language('=html').buildAsset("build-system/10.5-system-tool/build.zig")) -**Output** +**出力** ``` zig-out @@ -315,12 +274,11 @@ zig-out └── word.txt ``` -Note how `captureStdOut` creates a temporary file with the output of the `jq` invocation. +`captureStdOut`が`jq`の呼び出しの出力を持つ一時ファイルを作成する方法に注目してください。 -## [Running the Project's Tools]($heading.id('project-tools')) +## [プロジェクトのツールの実行]($heading.id('project-tools')) -This version of hello world expects to find a `word.txt` file in the same path, -and we want to produce it at build-time by invoking a Zig program on a JSON file. +このバージョンのhello worldは、同じパスに `word.txt` ファイルがあることを期待しており、ビルド時にJSONファイルにZigプログラムを呼びだして生成したいと考えています。 **`tools/words.json`** @@ -338,17 +296,17 @@ and we want to produce it at build-time by invoking a Zig program on a JSON file []($code.language('=html').buildAsset("build-system/11-zig-tool/build.zig")) -**Output** +**出力** ``` zig-out ├── hello └── word.txt ``` -## [Producing Assets for `@embedFile`]($heading.id('embed-file')) +## [`@embedFile`のためのアセットの生成]($heading.id('embed-file')) -This version of hello world wants to `@embedFile` an asset generated at build time, -which we're going to produce using a tool written in Zig. +このバージョンのhello worldはビルド時に生成されたアセットを`@embedFile`したいと考えており、 +Zigで書かれたツールを使用して生成します。 **`tools/words.json`** @@ -366,7 +324,7 @@ which we're going to produce using a tool written in Zig. []($code.language('=html').buildAsset("build-system/12-embedfile/build.zig")) -**Output** +**出力** ``` zig-out/ @@ -374,15 +332,14 @@ zig-out/    └── hello ``` -## [Generating Zig Source Code]($heading.id('generating-zig')) -This build file uses a Zig program to generate a Zig file and then exposes it -to the main program as a module dependency. +## [Zigソースコードの生成]($heading.id('generating-zig')) +このビルドファイルはZigプログラムを使用してZigファイルを生成し、それをモジュール依存関係としてメインプログラムに公開します。 []($code.language('=html').buildAsset("build-system/13-import/src/main.zig")) []($code.language('=html').buildAsset("build-system/13-import/tools/generate_struct.zig")) []($code.language('=html').buildAsset("build-system/13-import/build.zig")) -**Output** +**出力 ``` zig-out/ @@ -390,41 +347,32 @@ zig-out/    └── hello ``` -## [Dealing With One or More Generated Files]($heading.id('write-files')) +## [1つまたは複数の生成されたファイルの処理]($heading.id('write-files')) -The **WriteFiles** step provides a way to generate one or more files which -share a parent directory. The generated directory lives inside the local `.zig-cache`, -and each generated file is independently available as a `std.Build.LazyPath`. -The parent directory itself is also available as a `LazyPath`. +**WriteFiles**ステップは、親ディレクトリを共有する1つまたは複数のファイルを生成する方法を提供します。 +生成されたディレクトリはローカルの`.zig-cache`内にあり、生成された各ファイルは個別に`std.Build.LazyPath`として利用可能です。 +親ディレクトリ自体も`LazyPath`として利用可能です。 -This API supports writing arbitrary strings to the generated directory as well -as copying files into it. +このAPIは、生成されたディレクトリに任意の文字列を書き込んだり、ファイルをそこにコピーしたりすることをサポートしています。 []($code.language('=html').buildAsset("build-system/write-files/src/main.zig")) []($code.language('=html').buildAsset("build-system/write-files/build.zig")) -**Output** +**出力** ``` zig-out/ └── project.tar.gz ``` -## [Mutating Source Files in Place]($heading.id('mutating-source')) +## [ソースファイルのその場での変更]($heading.id('mutating-source')) + +一般的ではありませんが、プロジェクトが生成されたファイルをバージョン管理にコミットすることがあります。これは、生成されたファイルが滅多に更新されず、更新プロセスに負担のかかるシステム依存関係がある場合に役立ちますが、更新プロセス中のみです。 -It is uncommon, but sometimes the case that a project commits generated files -into version control. This can be useful when the generated files are seldomly updated -and have burdensome system dependencies for the update process, but *only* during the -update process. -For this, **WriteFiles** provides a way to accomplish this task. This is a feature that -[will be extracted from WriteFiles into its own Build Step](https://github.com/ziglang/zig/issues/14944) -in a future Zig version. +このために、**WriteFiles**はこのタスクを達成する方法を提供します。これは将来のZigのバージョンで[WriteFilesから独自のビルドステップに抽出される予定の機能](https://github.com/ziglang/zig/issues/14944)です。 -Be careful with this functionality; it should not be used during the normal -build process, but as a utility run by a developer with intention to update -source files, which will then be committed to version control. If it is done -during the normal build process, it will cause caching and concurrency bugs. +この機能は注意して使用してください。通常のビルドプロセス中ではなく、ソースファイルを更新する意図を持った開発者が実行するユーティリティとして使用すべきで、それらはバージョン管理にコミットされます。通常のビルドプロセス中に行われると、キャッシングと並行性のバグを引き起こします。 []($code.language('=html').buildAsset("build-system/mutate-source-files/tools/proto_gen.zig")) []($code.language('=html').buildAsset("build-system/mutate-source-files/src/main.zig")) @@ -441,18 +389,18 @@ update-protocol success ``` -After running this command, `src/protocol.zig` is updated in place. +このコマンドを実行すると、`src/protocol.zig`がその場で更新されます。 -# [Handy Examples]($heading.id('examples')) +# [便利な例]($heading.id('examples')) -## [Build for multiple targets to make a release]($heading.id('release')) +## [リリース作成のための複数のターゲットビルド]($heading.id('release')) -In this example we're going to change some defaults when creating an `InstallArtifact` step in order to put the build for each target into a separate subdirectory inside the install path. +この例では、`InstallArtifact`ステップを作成する際にいくつかのデフォルトを変更し、各ターゲットのビルドをインストールパス内の別々のサブディレクトリに配置します。 []($code.language('=html').buildAsset("build-system/10-release/build.zig")) []($code.language('=html').buildAsset("build-system/10-release/hello.zig")) -**Output** +**出力** ``` zig-out From 7c2236df418a88920eadeaacf0b46cb5956588b5 Mon Sep 17 00:00:00 2001 From: ekusiadadus Date: Sat, 10 May 2025 01:08:05 +0900 Subject: [PATCH 6/8] chore: udpate title --- content/ja-JP/learn/build-system.smd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja-JP/learn/build-system.smd b/content/ja-JP/learn/build-system.smd index 9a0b88141..1701e32e3 100644 --- a/content/ja-JP/learn/build-system.smd +++ b/content/ja-JP/learn/build-system.smd @@ -1,10 +1,10 @@ --- -.title = "Zig ビルドシステム", +.title = "Zigビルドシステム", .author = "", .date = @date("2024-08-07:00:00:00"), .layout = "page.shtml", .custom = { - "mobile_menu_title": "Zig ビルドシステム", + "mobile_menu_title": "Zigビルドシステム", "toc": true, }, --- From f63f0bde561e5f52c4b632f8a6ca7f6986c7ac31 Mon Sep 17 00:00:00 2001 From: ekusiadadus Date: Sat, 10 May 2025 01:09:26 +0900 Subject: [PATCH 7/8] fix: index for zig build system japanese summary --- content/ja-JP/learn/index.smd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja-JP/learn/index.smd b/content/ja-JP/learn/index.smd index ae309035e..cb49ce60e 100644 --- a/content/ja-JP/learn/index.smd +++ b/content/ja-JP/learn/index.smd @@ -16,8 +16,8 @@ to understanding its philosophy. This section is eventually going to be bundled with Zig's standard library documentation, but in the meantime you can browse it from here. -- [Zig Build System](./build-system/) -Introduction to the Zig build system. +- [Zigビルドシステム](./build-system/) +Zigビルドシステムの入門 ## はじめに これらはすべて、さまざまなバックグラウンドを持つプログラマーを対象としたZigの入門書です。 From 524d5743f9ac123fe6297117efc00cc0b5d8dbc0 Mon Sep 17 00:00:00 2001 From: ekusiadadus Date: Sat, 10 May 2025 01:11:54 +0900 Subject: [PATCH 8/8] fix: sysntax error for output section --- content/ja-JP/learn/build-system.smd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja-JP/learn/build-system.smd b/content/ja-JP/learn/build-system.smd index 1701e32e3..02dee27dc 100644 --- a/content/ja-JP/learn/build-system.smd +++ b/content/ja-JP/learn/build-system.smd @@ -339,7 +339,7 @@ zig-out/ []($code.language('=html').buildAsset("build-system/13-import/tools/generate_struct.zig")) []($code.language('=html').buildAsset("build-system/13-import/build.zig")) -**出力 +**出力** ``` zig-out/