[pacman-dev] [PATCH 2/5] meson.build: Fix detection of symbols

Mark Weiman mark.weiman at markzz.com
Mon Apr 19 14:28:22 UTC 2021


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 <allan at archlinux.org>
> > 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


More information about the pacman-dev mailing list