+ `std.mem.split` is deprecated, `splitScalar` seems like the intended choice here
+ zig files should be formatted according to `zig fmt`

#4150 introduced a default value for linux_display_backend,
which makes X11-only systems fail to build.

* [build.zig] Overridable definitions from config.h
The new Options field "config" holds a string the user can set in the
format "-Dflag_a=1 -Dflag_b=0 ..." to override the values set in
`config.h`.
The file is parsed and the default values are appended to the
compilation flags, if the user doesn't override them.
The user string is appended to the compilation flags.
The "-DEXTERNAL_CONFIG_FLAGS" is added to prevent "config.h" inclusion.

Note: a certain format is assumed for the formatting of config.h
Note: this commit references the closed issue #3516

* [build.zig] Only SUPPORT_* definitions are overridable

Lines from `config.h` which contains "SUPPORT" are added to compilation after being parsed:
- remove whitespace
- format to preprocessor option https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html

The user supplied flags have priority over the ones read from the file.

NOTE: extension to commit 4da7f82e6f912485351167da3bbc91807371fdee, the logic is simplified
because the SUPPORT flags only have binary values, which makes them easier to parse.

* Zig Both Linux Desktop Platform Support

* Formating and Default Fix
Made formating fit within raylib standards and changed the default option to support both X11 and wayland on Linux.

* caught one hiding tab

`@This()` was naively passed to `dependencyFromBuildZig` while inside
a file that is not actually the build file, causing a panic when
actually used. Passing `@import("../build.zig")` fixes this.

When addRaygui is used from an external build, for example in a
bindings project, the build of a generated `raygui.c` fails with
"raylib.h not found" error from the compiler.

I've traced this down to a raylib step not adding its `src/` to the
shared list of include paths using `addIncludePath` but relying on
`addCSourceFiles` `.root` to provide the implicit include path for
raylib proper's own files.

If raygui is later added to the step the compiler won't know where
to look for `raylib.h` and friends and will fail to build.

This change simply adds raylib's `src/` to the include path list.

* Fix for issue #4010

Split the code for Zig's master branch and >= 0.12.0 due to changes in https://github.com/ziglang/zig/pull/19623

* Restore the cache_include path which was removed in error

Accidently removed a couple lines I didn't mean to 🙈

This works in zig 0.12, LazyPath.path has been removed in zig 0.13

Co-authored-by: CosmicBagel <>

Added `opengl_version` option to `src/build.zig`.

* Remove support for 0.11.0, and make build script more idiomatic
+ remove all 0.11.0 compatibility functions
+ remove most LazyPath .path variants
  + I didn't touch emscripten, I don't know if its relative or absolute
+ change all absolute paths to use .cwd_relative
+ only use the builder allocator
+ have local dependencies use the package manager
+ make adding raygui more flexible
+ use zig-cache for generated wayland files

* Remove support for 0.11.0 in examples/build.zig

* update examples further and add clarifying comment on addRaygui

* fix local dependency breakage

* revert accidental change in include path

* update to latest zig, and don't use srcdir

* preserve compatibility, simplify Child.run compatibility

The changes brought by #3891 uses `std.process.Child.run` which was
renamed from `std.process.Child.exec` in Zig version 0.11.0. This commit
adds a version check to use the appropriate function names.

Additionally, the `linux_display_backend` configuration option is added
so users can set it when running `zig build` with the `-D` option or
when using raylib as a dependency.

* Fixes zig build that was broken on #3863

* Make this work with wayland

The purpose of this directory in GLFW is to provide some headers that
"mingw.org" doesn't. Raylib has long been unable to build with mingw.org
due to using certain symbols that aren't exposed in their headers.
(_ftelli64 and _access, among others.). Mingw-w64 already has the
necessary headers included, and doesn't need any of these external
implementations. For some reason, this also causes the following error
when building with Visual Studio's clang:

clang  -c rglfw.c -Wall -D_GNU_SOURCE -DPLATFORM_DESKTOP -DGRAPHICS_API_OPENGL_33 -Wno-missing-braces -Werror=pointer-arith -fno-strict-aliasing  -std=c99 -O1 -Werror=implicit-function-declaration -I. -Iexternal/glfw/include -Iexternal/glfw/deps/mingw
In file included from rglfw.c:61:
In file included from ./external/glfw/src/init.c:30:
In file included from ./external/glfw/src/internal.h:331:
In file included from ./external/glfw/src/platform.h:31:
In file included from ./external/glfw/src/win32_platform.h:70:
external/glfw/deps/mingw\xinput.h:227:26: error: a parameter list without types is only allowed in a function definition
  227 | void WINAPI XInputEnable(WINBOOL);
      |

If the last -Iexternal/glfw/deps/mingw is removed, the build works fine.

So, this workaround causes other problems, while not actually helping
raylib.

0bb605cd79/src/CMakeLists.txt (L272-L279)

GLFW's CMakeLists.txt first checks if either dinput.h or xinput.h are
provided by the toolchain, before telling the compiler to search for
headers in that directory. For EVERY compiler that can build raylib,
this is true.

In summary: This directory causes issues when building with some
compilers, and every toolchain that needs this workaround can't build
raylib anyway.

* update build.zig to 0.12.0-dev.2139 and add shared lib option

* add no-sanitize workarounds

* update build.zig for latest zig 0.12.0dev while still allowing 0.11.0

* update examples/build.zig and add nicer message for type mismatch

* allow zig 0.11.0 and 0.12.0dev to build raylib

* update comment

for zig master (2023-10-17)

This reverts commit 540ad99442.

* update build.zig for zig 0.11.0

* fix build.zig in examples to install executable correctly

* discard build.zig, only use src/build.zig, to avoid annoying zig-out path problem

* update zig version note

This reverts commit a316f9e7fc.

Issue #1891 was fixed again, so this is no longer needed.

Zig debug builds automatically enable ubsan.
As the fix for #1891 had to be reverted, debug builds using zig will crash like so:

```
Illegal instruction at address 0x3237d2
raylib/src/rlgl.h:3690:91: 0x3237d2 in rlDrawVertexArrayElements (/home/rcorre/src/raylib-zig-template/raylib/src/rcore.c)
    glDrawElements(GL_TRIANGLES, count, GL_UNSIGNED_SHORT, (const unsigned short *)buffer + offset);
```

This disables UBSAN when using zig to build raylib.

ref.: https://github.com/ziglang/zig/pull/16446

- Adds an option -Dplatform_drm when using zig build
- When building for linux, checks whether -Dplatform_drm is present and configures the build accordingly.

* Add options to zig compile options

Support for compiling with raygui, raymath, and physac.
Also outputs the required headers.

Raygui should be located `../raygui` relative to the repo root
Physac should be located `../physac` relative to the repo root

This behavior matches options in the Makefile

* Move Options struct

* Remove physac, explicit raymath, always copy rlgl.h and raymath.h

* Remove unused options from build.zig

* Add srcdir as include path for raygui.h

* Revert "Fixed broken build.zig files. Now works with latest stable compiler (as of commit, latest is 0.10.1) (#3045)"

This reverts commit de748dfffe so that zig
build script works with master branch of zig.

* Added a note to build.zig files that denotes what version of zig they have been tested with.

* Standardised the note in the build.zig files

Co-authored-by: Talha Qamar <qamartalha@proton.me>

also, adds package manager support

* Add WASM support for Zig build

* Improve Web example building

* Remove emscript example building with Zig again

* Readd windows emscripten variables

* build.zig: let user decide how to set build mode

This should delegate the responsibility of calling `standardReleaseOptions` and setting the build mode of the `*LibExeObjStep` step to the caller, especially since this might not be the process by which one wants to determine the build mode.

Also changes hides `getSrcDir` to enforce usage of `srcdir`, and asserts that the file is in fact inside a directory.

* build.zig: set root_src param to `null`

Supplying the header file as the root source here appears to cause a linker warning of the form:
```
LLD Link... warning(link): unexpected LLD stderr:
ld.lld: warning: {build_root}/zig-cache/o/{hash}/libraylib.a: archive member '{build_root}/zig-cache/o/{hash}/raylib.o' is neither ET_REL nor LLVM bitcode
```
Passing `null` instead fixes it.

zig `master` now enforces to use addIncludePath instead of addIncludeDir