build.zig: Clean up my mess

[sagehane]

I am absolutely dumb and cannot make proper PRs. I'll make this a draft until someone can tell me it works.

Context:
#4380 (comment)

[raysan5]

@Not-Nik Please, could you take a look at this build.zig improvement?

[Not-Nik]

Both plain build (zig build) and raylib-zig build (as a .zon dependency) work on my MacBook 👍

[Yerdun]

@sagehane Hi, I tried using your fix; while I am able to compile raylib by running zig build directly in the repository, it is not working for me as a dependency. For some reason, srcDir() seems to repeat the dependency's directory.

Here is a log showing what happens on my machine:

/tmp/raylib-zig-dep-bug % zig build
install
└─ install raylib-zig-dep-bug
   └─ zig build-exe raylib-zig-dep-bug Debug native
      └─ WriteFile raylib.h failure
error: FileNotFound: /tmp/raylib-zig-dep-bug/raylib/raylib/src/raylib.h

Unfortunately, I do not know enough about Zig to help with fixing this problem. I apologize that I cannot do more.

If you would like to test this yourself, I have provided a repo containing this sample project here. I am using Zig version 0.12.1; my build.zig is not configured to work with 0.13.

Please let me know if there is any additional information I could provide. Thanks.

[rstefanic]

@Yerdun I have a similar repo here configured for 0.13.0. I'm just sharing it here again for more testing.

https://github.com/rstefanic/raylib-zig-build-bug

[sagehane]

I knew my incompetence would get me again. @Yerdun, thanks for the feedback. You're using b.dependency unlike us two, which explains why you're hitting an error I overlooked. This is very interesting but I also honestly don't know the appropriate fix here. I don't even know if this is intended behaviour by upstream.

Regardless, I'm starting to think that the use of @src logic is misguided in the first place... I was trying to fix compile errors without having to change the logic left by the people who previously edited the src/build.zig file but it clearly isn't working. If I can't think of a good way to overcome this issue (which I doubt I will), I'll probably consider a patch that removes src/build.zig and merges the content with build.zig. I honestly don't see why two are needed anyways.

The other solution is to keep src/build.zig and let it be "broken" when compiling from src/. (But why?)

[Not-Nik]

I think Ray opposed that some time ago. IIRC we first had a single build.zig and then it was split into two.

Maybe we can rename src/build.zig to avoid people building in src, because I really don't see a reason why that should be possible.

[raysan5]

@Not-Nik Why build.zig was split into two? Wasn't src/build.zig enough, same as src/Makefile?

[sagehane]

After looking at this project some more, if I'm understanding this correctly, it looks like Raygui support is currently attempted by expecting the user to have cloned the Raylib and Raygui repo with a shared parent directory. With what the Zig build system is capable of, this looks like a terrible hack. I should look into that too.

[sagehane]

The config option also looks broken at a glance as attempting zig build -Dconfig="-Werror" causes a compile error but something like zig build -Dconfig="-Werror -Wall" doesn't cause a compile error. My guess is that the logic is broken such that it will only work if only 1 cflag is supplied.

[sagehane]

Another weird quirk:

raylib/src/build.zig

Lines 88 to 110 in 99ff770

	if (options.config.len > 0) {
	const file = b.pathJoin(&.{ srcDir(b), "config.h" });
	const content = try std.fs.cwd().readFileAlloc(b.allocator, file, std.math.maxInt(usize));
	defer b.allocator.free(content);
	var lines = std.mem.splitScalar(u8, content, '\n');
	while (lines.next()) |line| {
	if (!std.mem.containsAtLeast(u8, line, 1, "SUPPORT")) continue;
	if (std.mem.startsWith(u8, line, "//")) continue;
	if (std.mem.startsWith(u8, line, "#if")) continue;
	var flag = std.mem.trimLeft(u8, line, " \t"); // Trim whitespace
	flag = flag["#define ".len - 1 ..]; // Remove #define
	flag = std.mem.trimLeft(u8, flag, " \t"); // Trim whitespace
	flag = flag[0 .. std.mem.indexOf(u8, flag, " ") orelse continue]; // Flag is only one word, so capture till space
	flag = try std.fmt.allocPrint(b.allocator, "-D{s}", .{flag}); // Prepend with -D
	// If user specifies the flag skip it
	if (std.mem.containsAtLeast(u8, options.config, 1, flag)) continue;
	// Append default value from config.h to compile flags
	try raylib_flags_arr.append(b.allocator, flag);
	}

This implies that the values of config.h would not be passed as cflags if users don't specify any custom build flags.

I'm not too familiar with C but is this intended behaviour? config.h should be sourced anyways, so if cflags aren't capable of overriding them, there's no point. If cflags can override them, I don't see the need for this code.

---

EDIT: I see, it has to do with how EXTERNAL_CONFIG_FLAGS affect where config.h should be sourced.

[sagehane]

@Yerdun, I think I figured it out. It's the logic here:

raylib/src/build.zig

Lines 89 to 90 in 99ff770

	const file = b.pathJoin(&.{ srcDir(b), "config.h" });
	const content = try std.fs.cwd().readFileAlloc(b.allocator, file, std.math.maxInt(usize));

readFileAlloc is agnostic of the build system so, given a relative path, it will always try that literal path.

Something like const file = b.pathFromRoot("src/config.h"); worked on my branch where I moved src/build.zig to build.zig.

/// This is low-level implementation details of the build system, not meant to
/// be called by users' build scripts. Even in the build system itself it is a
/// code smell to call this function.
pub fn pathFromRoot(b: *Build, sub_path: []const u8) []u8 {
    return b.pathResolve(&.{ b.build_root.path orelse ".", sub_path });
}

This does suggest that pathFromRoot should be avoided so I'll try to see if there's a better way.

[Not-Nik]

@Not-Nik Why build.zig was split into two? Wasn't src/build.zig enough, same as src/Makefile?

The build.zig is required to enable using raylib as a dependency with Zig's package manager

[sagehane]

The convention in Zig projects is to have a build.zig in the root dir. All tooling depends on build.zig at root and would be much harder for the package manager to work otherwise.

In the case of big monorepos with multiple components, one reasonable way to handle that would probably be to have a build.zig in the root of each component and have them exposed as packages to the build.zig in the root dir.

$ tree
.
├── a
│   └── build.zig
├── b
│   └── build.zig
└── build.zig

Something like this is perfectly legal and fine, but it seems overkill for the state of raylib as it seems to just be one library.

[Not-Nik]

Well we also have the examples, so it does make sense to split the build file.

[sagehane]

Oh, I totally didn't realise that. Then I'll also try to get this PR to a properly working state in parallel with the other one so it's easier to decide. I think it might involve using newer Zig features and hence require bumping the minimum supported version of Zig to 0.13.0, depending on how things go.

[raysan5]

@Not-Nik @sagehane Supporting Zig 0.13.0 as the minimum version sounds good to me, it has been out for some time. When is 0.14.0 released?

An unrelated question: can I use build.zig on Windows to cross-build raylin and a C project for Linux and macOS?

[sagehane]

When is 0.14.0 released?

Zig's release schedule currently is meant to match that of LLVM (usually lagging by a few months), which releases twice a year.

An unrelated question: can I use build.zig on Windows to cross-build raylin and a C project for Linux and macOS?

Cross-compiling using Zig is usually very easy. One issue for cross-compiling is that, at least on Linux, Raylib depends on libraries that are normally dynamically linked like libX11, OpenGL, Wayland, etc. I'm not quite sure how this works and it's hard for me to test on NixOS as it's not FHS-compliant, meaning all the dynamic libraries Raylib might expect aren't where they normally would be in other Linux distros.

[sagehane]

So, I came up with https://github.com/sagehane/raylib/tree/zig_patch_3 for another branch with a different way of fixing build.zig. It uses some comptime magic with a new function in src/build.zig called addRaylibType to circumvent a dumb compile error I've been having when trying to use raylib with b.dependency from other projects. There must be a better way but it'll do for now.

After thinking about it, I've concluded that:

• I think it makes more sense to remove the src/build.zig file. The one in the examples dir should stay though.
• The addRaylib function seems misguided to me. The idiomatic way to add dependencies using the package manager should be via b.dependency like from the example repo by @Yerdun. It only makes it slightly easier to depend on Raygui.
  • It's currently useful as a helper function internal to the project, but I don't think it needs to be exposed with pub.
  • As for Raygui support, I have no idea how to test it as I've only used a small subset of what Raylib offers so far.
• There's also a logic bug in the current src/build.zig such that it can only accept 1 cflag via -Dconfig.
  • I think it would be better to delete all the logic dedicated to trying to apply the default config.h options. Handling this alone would solve the immediate problem. The rest can technically be handled later.
    • Edit: Okay, I tried not depending on config.h and it seems to require manually setting quite a lot of values. Probably infeasible for most users.

[Yerdun]

@rstefanic

@Yerdun I have a similar repo here configured for 0.13.0. I'm just sharing it here again for more testing.

Thanks for sharing. Can confirm I get the same results when following the instructions in your readme.

---

@raysan5

An unrelated question: can I use build.zig on Windows to cross-build raylin and a C project for Linux and macOS?

You should be able to. I've been using Zig as my build system specifically to cross compile. That said, I have not tried from Windows -> Linux before, only the other way around.

From my experience, it works quite well, aside from some problems specific to my use cases. For example, I can't get custom cflags to be recognized when cross compiling. I plan on looking into this more and eventually open an issue about it.

---

@sagehane Thanks a lot for looking into all this. I was actually going to post an issue regarding the "can only use one cflag through build.zig" problem, but you noticed it before I could say anything, haha.

My sample project was also intended to demonstrate the single cflag problem. I actually haven't checked if the program actually works yet, but after I do that, I'll try out the changes proposed in zig_patch_3 and #4393, and see how they go. Will also test if cross compilation takes into account custom cflags passed through Options.config.

[wwderw]

@Not-Nik @sagehane Supporting Zig 0.13.0 as the minimum version sounds good to me, it has been out for some time. When is 0.14.0 released?

An unrelated question: can I use build.zig on Windows to cross-build raylin and a C project for Linux and macOS?

Zig is what I use for cross compiling, but I'm on Linux, so it will be cross compiling to Windows. That may be an easier path compared to the other way around. I have not tried it for Mac, so I have no experience there. Although, while the build.zig seems to be influx, I haven't had successful builds as of yet, but normally it does work well.

[raysan5]

@sagehane @Not-Nik thanks for the review, merged!

[sagehane]

I hate GitHub. It doesn't let me set a PR back to draft mode without first deleting it and making a new PR. This PR wasn't truly ready to be merged because it still resulted in a small logic error when supplying -Dconfig (which I found out after undrafting it...), not to mention that there was some broken logic there before I started looking into it.

That said, I think this commit does solve the primary/immediate compile error that users would run into.