zig build: The breakings will continue until morale improves. #14498
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andrewrk
added
enhancement
scheibo
reviewed
Jan 31, 2023
* introduce the concept of maps to user input options, but don't implement it for command line arg parsing yet. * remove setPreferredReleaseMode and standardReleaseOptions in favor of standardOptimizeOption which has a future-proof options parameter.
This is a breaking change that makes the API for creating build artifacts no longer have any period of time where the target and optimization mode are not set.
I've been wanting to do this for along time.
And only detect native target in LibExeObjStep once, in create().
This matches the nomenclature internally: a Compilation is the main type that represents a single invokation of the compiler.
These declarations are now aliases of their new APIs and marked as deprecated via doc comments: * std.build.Builder * std.build * std.Build.LibExeObjStep
Usage of `catch unreachable` in build scripts is completely harmless because build scripts are always run in Debug mode, however, it sets a poor example for beginners to learn from.
This API only depends on std.Target and is extremely useful in build scripts when populating configure files.
This regressed earlier in this branch.
andrewrk
force-pushed
the
zig-build-api
branch
from
6c30419 to
8d37c6f
Compare
This was referenced Feb 4, 2023
Closed
mattnite
pushed a commit
to ZigEmbeddedGroup/microzig
that referenced
this pull request
Feb 6, 2023
rrbutani
added a commit
to rrbutani/rosettaboy
that referenced
this pull request
Feb 8, 2023
This is needed for the nix package to build on macOS. Also bumps the zig deps and has `build.zig` changes to match ziglang/zig#14498 and ziglang/zig#14538.
jbboehr
pushed a commit
to jbboehr/rosettaboy
that referenced
this pull request
Feb 9, 2023
This is needed for the nix package to build on macOS. Also bumps the zig deps and has `build.zig` changes to match ziglang/zig#14498 and ziglang/zig#14538.
jbboehr
pushed a commit
to jbboehr/rosettaboy
that referenced
this pull request
Feb 10, 2023
This is needed for the nix package to build on macOS. Also bumps the zig deps and has `build.zig` changes to match ziglang/zig#14498 and ziglang/zig#14538.
jbboehr
pushed a commit
to jbboehr/rosettaboy
that referenced
this pull request
Feb 10, 2023
This is needed for the nix package to build on macOS. * bump the zig deps and has `build.zig` changes to match ziglang/zig#14498 and ziglang/zig#14538. * only change preInstall on darwin * drop the `SDL2` lowercase fix - doesn't appear to be necessary anymore. * upgrade zig in github actions and pass in nim/zig versions (@jbboehr)
jbboehr
pushed a commit
to jbboehr/rosettaboy
that referenced
this pull request
Feb 10, 2023
This is needed for the nix package to build on macOS. * bump the zig deps and has `build.zig` changes to match ziglang/zig#14498 and ziglang/zig#14538. * only change preInstall on darwin * drop the `SDL2` lowercase fix - doesn't appear to be necessary anymore. * upgrade zig in github actions and pass in nim/zig versions (@jbboehr)
jbboehr
pushed a commit
to jbboehr/rosettaboy
that referenced
this pull request
Feb 10, 2023
This is needed for the nix package to build on macOS. * bump the zig deps and has `build.zig` changes to match ziglang/zig#14498 and ziglang/zig#14538. * only change preInstall on darwin * drop the `SDL2` lowercase fix - doesn't appear to be necessary anymore. * upgrade zig in github actions and pass in nim/zig versions (@jbboehr)
This was referenced Feb 14, 2023
ikskuh
pushed a commit
to zig-community/user-map
that referenced
this pull request
Feb 15, 2023
ikskuh
pushed a commit
to ziglibs/ini
that referenced
this pull request
Feb 15, 2023
Closed
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 23, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 26, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 26, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 27, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
matklad
added a commit
to tigerbeetle/tigerbeetle
that referenced
this pull request
Aug 27, 2024
This moves multiversion from release.zig to build.zig, so that you can
just build a multiversion binary normally, eg:
```
$ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 -Dtarget=x86_64-linux
$ ./tigerbeetle multiversion ./tigerbeetle
multiversioning.exe_path=./tigerbeetle
multiversioning.absolute_exe_path=/home/matklad/p/tb/work/tigerbeetle
multiversioning.releases_bundled={ 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.15.7 }
...
```
You can pass `-Dmultiversion=latest` to fetch the latest release from
GitHub.
Note that `-Dtarget=aarch64-macos` will build a _universal_ macos image
(this _is_ confusing flag name, but I don't see a simple non-ambigious
solution here).
As a bonus, multiversion build now should work on any host, and not on
x86_64 linux only.
Implementation wise, the bulk of work happens in
`build_multiversion.zig` program, which is invoked from build.zig as a
custom Run step. Why not encode all that logic direcctly into build.zig?
The main reason is adrewrk, the most famous Zig troll. His favorite way
of trolling Zig developers is by regularly breaking the API of build.zig:
ziglang/zig#14498
The next planned trolling is to separate "configure" and "make" phases
of `build.zig` into physically separate processes, and remove support
for custom steps:
ziglang/zig#20981
In this PR, we are going to troll adrewrk _back_ by fixing our code even
before it gets broken, and by making our custom step a Run step instead.
That being said, it I have split `gh release download` into a separate
step, so that is properly cached.
robbielyman
added a commit
to robbielyman/EmbedFile.zig
that referenced
this pull request
Jan 2, 2025
this change should hopefully be more future-proof: in light of ziglang/zig#14498, collecting the EmbedFile.zig logic as a Run Step is likely to be the preferred (indeed, only) way to extend the Build system in the future. also, by breaking out the work originally in `make` into a collection of other steps, EmbedFile.zig should hopefully correctly work with the Zig build syste's caching system. (Previously, I found that updating file contents were not reflected in the `@embedFile` calls.) adds `writeSources`, which creates and returns a named `WriteFile` step which collects everything the `EmbedFile` step touches and outputs it into one directory. also, one can now use the `embed-file` executable standalone if desired. BREAKING CHANGE: the signatures of `addFile` and `addDirectory` have changed. taking `sub_path` as an argument was incorrect. BREAKING CHANGE: `createModule` is removed; instead use `embed_file.module` directly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
std.buildandstd.build.Builderintostd.BuildsetTargetandsetBuildMode; use an options struct forb.addExecutableand friendsexample of the flexibility this system brings (this is why we explicitly pass around optimization mode and target everywhere)