zig icon indicating copy to clipboard operation
zig copied to clipboard

Correct cmakedefine implementation

Open Jan200101 opened this issue 2 years ago • 5 comments
trafficstars

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.

Jan200101 avatar Jun 14 '23 20:06 Jan200101

This sounds like something, for which a standalone test would be nice to see what stuff is handled and what edge cases not.

matu3ba avatar Jun 14 '23 21:06 matu3ba

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?

Jan200101 avatar Jun 15 '23 14:06 Jan200101

variable substition with @VAR@ and ${VAR} is now implemented.

Its been separated into a function since #15017 could reuse this.

Tests will come next.

Jan200101 avatar Jun 19 '23 16:06 Jan200101

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?

Jan200101 avatar Jun 20 '23 09:06 Jan200101

CI broke because of #16046, will fix whenever

Jan200101 avatar Jun 20 '23 11:06 Jan200101

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.

Jan200101 avatar Jun 21 '23 19:06 Jan200101

Thanks! Good work

andrewrk avatar Jun 24 '23 06:06 andrewrk