Implement Meson ConfigHeader support #31363

❯ zig test lib/std/std.zig --zig-lib-dir lib --test-filter "Step.ConfigHeader"
All 71 tests passed.

Quote strings and make literals bare

Add test

Currently using this branch for porting glib to the Zig build system at github.com/bernardassan/Glib@343190ea75/build.zig (L251)

Signed-off-by: Bernard Assan mega.alpha100@gmail.com

Hi @bernardassan, FYI there is #31229. I'm linking both together so if either gets merged its easier to close the other.

@Tomcat-42, Your PR #31229 looks good. I will test it tomorrow on my repo and give feedback.

But at a quick glance, any reason why you formatted both .ident and .string to be #define {s} {s}? In meson, there is the concept of set_quoted which outputs a quoted string, so I'm thinking why not make the distinction obvious by making .ident output the raw identifier while .string outputs a quoted string #define {s} \"{s}\" just like is done by renderValueC(). This helps prevent needing to manually quote all quoted strings. You can have a look at github.com/bernardassan/Glib@37eb57476a/build.zig (L322) to see how it helps to make literal and quoted strings obvious instead of .string just being another way of doing .ident, which presents 2 ways of doing the same thing.

Hi @bernardassan

But at a quick glance, any reason why you formatted both .ident and .string to be #define {s} {s}?

Despite from my lack of deeper knowledge on meson, no, no specific reason. I was porting some wayland related libs that all used meson, and and figured it was worth trying to fix it upstream.

I will test it tomorrow on my repo and give feedback.

Could you please make a code review too? Like for this set_quoted case and others?

@bernardassan wrote in #31363 (comment):

But at a quick glance, any reason why you formatted both .ident and .string to be #define {s} {s}?

If I may interject with my own reason why it should be implemented this way, it's important to not automatically quote strings inserted as variables because certain headers insert code procedurally generated at build-time (example from GTK/GDK: https://codeberg.org/GalaxyShard/gtk-headers/src/branch/main/gdk/version/gdkversionmacros.h.in see @GDK_VERSIONS@).

.ident, as far as I know, must be literals embedded in the code and cannot be created procedurally within the build script, thus strings must be used. If strings were automatically quoted, Zig wouldn't support these types of meson config headers.

Last I checked, this behavior was also consistent with CMake and Autoconf. The renderValue functions do seem to automatically quote strings, but these functions aren't used for variables so I believe it would be fine to automatically quote strings in that case.

@GalaxyShard wrote in #31363 (comment):

If I may interject with my own reason why it should be implemented this way, it's important to not automatically quote strings inserted as variables because certain headers insert code procedurally generated at build-time (example from GTK/GDK: https://codeberg.org/GalaxyShard/gtk-headers/src/branch/main/gdk/version/gdkversionmacros.h.in see @GDK_VERSIONS@).

This is a valid assessment, as you can't quote runtime-generated strings as enum literals, which are comptime known. But note that this is only true for autoconf-style variables @variable@, but we can quote strings just fine with #mesondefine. I will update the PR with this change

.ident, as far as I know, must be literals embedded in the code and cannot be created procedurally within the build script, thus strings must be used. If strings were automatically quoted, Zig wouldn't support these types of meson config headers.

As explained above. I guess because I solved my use case differently here github.com/bernardassan/Glib@37eb57476a/build/glib.zig (L64), this narrowed my view a bit.

Last I checked, this behavior was also consistent with CMake and Autoconf. The renderValue functions do seem to automatically quote strings, but these functions aren't used for variables, so I believe it would be fine to automatically quote strings in that case.

Note: that Cmake uses the same approach I am proposing above, where autoconf style @variable@ expansion doesn't quote strings, but #cmakedefine and #cmakedefine01 do quote.

@Tomcat-42, since the changes suggested on #31229 haven't been incorporated yet. I will update this PR and patch them here to unquote for autoconf-style variable, just like how autoconf and cmake already do, but quote for #mesondefine.

After all, quoting could be done by a simple function like

fnquote(comptimevalue:[]constu8)[]constu8{return"\""++value++"\"";}

@GalaxyShard and @Tomcat-42, can you test out this PR for me? It's working fine on my project.

Thanks for submitting this. I'm sitting on it for a while because I'm working on a build system change that will cause a lot of conflicts with this patch. However, any tests added here will be very useful in restoring functionality. In fact, the tests are almost the more valuable deliverable here! I haven't looked at the diff yet, just letting you know.

I will now post the same message in #31229.

Duly Noted.

Updated PR for the build system Configurer/Maker split