zig
zig copied to clipboard
Correct cmakedefine implementation
Changes the implementation behind cmakedefine and cmakedefine01 to match the actual cmake behavior.
Tested against https://github.com/Jan200101/cmakedefine-test, which can configure a test header against cmake, meson and zig.
The diff between the cmake and zig configured header with this PR
--- cmake_build/test.h 2023-06-14 22:55:53.531659521 +0200
+++ zig-cache/o/9dcd70028e62d4109280ca26a82c002c/config.h 2023-06-14 22:53:41.225032597 +0200
@@ -1,3 +1,4 @@
+/* This file was generated by ConfigHeader using the Zig Build System. */
// defined as "foo_content"
#define foo "foo_content"
@@ -46,3 +47,4 @@
// defined as 0, no value
#define nofoo 0
+
Currently only supports @var@ substition and not ${var}.
@var@ substition is also implemented in a very messy way, and I don't what would be the best way to clean it up, feedback on how to improve it would be useful.
This sounds like something, for which a standalone test would be nice to see what stuff is handled and what edge cases not.
This sounds like something, for which a standalone test would be nice to see what stuff is handled and what edge cases not.
Agreed, though should it just handle an example file with an expected result, or actually configure the header through cmake and compare it with the zig output. and should it be done all in one pass or in multiple smaller ones to see which specific use case breaks?
Cmake allows forcing only @VAR@ substition and meson requires you to explicitly choose between the two.
Should Zig also do this or simply support both?
variable substition with @VAR@ and ${VAR} is now implemented.
Its been separated into a function since #15017 could reuse this.
Tests will come next.
CI failure was expected, because I didn't zig fmt.
I made a standalone test, but I am unsure how to read the resulting config header, since it is only known after the step is already complete.
What is the best way to solve this? a step in-between that reads the files contents through some attribute?
CI broke because of #16046, will fix whenever
standalone test added that compares an example header against a pre-configured header generated using cmake 3.26.4.
Overall the logic may be crusty on some ends, but this appears to work pretty well.
Thanks! Good work