The result of configure is an .h file that have a HAVE_KERNEL_RWF_T define, or something similar.
In your C code you can #ifdef to select code with or without the HAVE_ feature.
In zig you don’t need any configure step.
In your Zig code you can use compile-time if statements to select the code with or without the feature.
C code: (config.h is generated from configure step)
What I am trying to do is “zig” a C library by replacing it’s original build system with zig build. I’ll edit the original question, because the word “converting” is wrong in this context.
Modifying the original library source code is not desirable as I only import it as a dependency.
Yes, I mainly followed Andrew’s ffmpeg build.zig but my original problem still remains: How to check the presence of a macro in a kernel header in build.zig. The guide you provide do not talk about that (and it’s a little out of date).
It’s in the any-linux-any directory which means that Zig has determined that this file is the same on every target.
If you look at the file, __kernel_rwf_t is unconditionally defined.
So, the answer to this question that this configure script is inefficiently trying to ask is “yes” and you may simply and accurately hard-code it in build.zig.
Under different conditions, it may be necessary to do something more complicated, but in this instance it is actually correct to delete that logic since that value is always defined.
Stuff like this is one of many reasons why zig build tends to be faster than autoconf.