On Tue, 2021-04-20 at 00:05 +1000, Allan McRae wrote: > On 19/4/21 9:34 pm, Emil Velikov wrote: > > On Mon, 19 Apr 2021 at 08:10, Allan McRae <[email protected]> > > wrote: > > > > > > On 17/4/21 1:45 pm, Mark Weiman wrote: > > > > This patch changes the behavior of meson to define > > > > configuration options > > > > *only* when the symbol checked is present. Currently, it > > > > defines all of > > > > them in config.h whether the symbol exists or not and the code > > > > that > > > > looks for it doesn't check the macro's value, but whether it's > > > > defined. > > > > > > > > > > Remember back when we used autotools and all this just worked! > > > :D > > > > > > Patch looks good to me. > > > > > Food for thought: > > > > Usually the more robust approach is to always set the respective > > defines to 0/1 and evaluate them directly (aka #if HAVE_). > > In addition one could set -Werror=undef in the build to catch any > > issues. > > > > This will produce clear traces with potential issues, while #if > > defined will silently fallback to the "other" path. > > If people are OK with the above, I will follow-up with some > > patches. > > > > Note: above suggestion is not meant to dismiss the original patch. > > > > > I still live in the good old autotools days where there were lots of > #undef in config.h... > > It appears some of that still happens. This is my build/config.h: > > #undef HAVE_STRUCT_STATFS_F_FLAGS > #define HAVE_STRUCT_STATVFS_F_FLAG > > But it is not consistent. >
This can be easily done by not using set10, but instead setting the values to true/false with set. That's why HAVE_STRUCT_STATFS_F_FLAGS is undef'd and those other ones that use set10 don't. I can modify this to mimick the old autotools behavior. > > I'm not sure whether the better solution is to add more #undef, or to > go > to the #if 0/1 style. > > Allan Mark
