Repository navigation
allow more flexible condition evaluation #35
Description
rules_cc_autoconf it's quite useful for bazel porting, I'm trying to base my meson header generation function on rules_cc_autoconf (https://github.com/comicfans/rules_cc_autoconf/tree/meson).
currently checks.AC_ macro supports condition to get 'and' behavior , this makes condition construction complex even for simple bool logic, for example
if HAVE_SYS_XATTR_H or HAVE_ATTR_XATTR_H:
define HAVE_XATTR
then I have to write something like
checks.AC_CHECK_HEADER('sys/xattr.h', define = "HAVE_SYS_XATTR_H"),
checks.AC_CHECK_HEADER('attr/xattr.h', define = "HAVE_ATTR_XATTR_H"),
checks.AC_DEFINE("NO_SYS_XATTR_H", requires = ["!HAVE_SYS_XATTR_H"]),
checks.AC_DEFINE("NO_ATTR_XATTR_H", requires= ["!HAVE_ATTR_XATTR_H"]),
checks.AC_DEFINE("NO_BOTH", requires = ["NO_SYS_XATTR_H", "NO_ATTR_XATTR_H"]),
checks.AC_DEFINE("HAVE_XATTR", requires = ["!NOT_BOTH"])it might also lead unexpected define.
I wonder if we can support arbitrary expression evaluation, for example a python helper , inject all checks as variable, then complex condition expression can be used ease the bazel port
Activity
comicfans commentedon Mar 2, 2026
I put my experiments here https://github.com/comicfans/rules_cc_autoconf/tree/meson/autoconf/private/expr_eval and use it in glib https://github.com/comicfans/glib/blob/bazel/defs.bzl , something like
it can generate almost identical config.h to native meson build script. I’d love to hear your thoughts on them, shall I improve it to be built-in feature of rules_cc_autoconf, or leave them in another module ?
abrisco commentedon Mar 2, 2026
Howdy! Thank you for trying the rules out! I have definitely run into the desire for this but never felt confident in a design for it. As I use these rules in more and more places I'm feeling the desire of #28 more and more and am nervous about expanding the interface of checks before that's thought out.
I have yet to try to port a project built with Meson but I have run into interactions with CMake (#29) that I'd like these rules to provide some conveniences around. So while the focus of these rules are still around Autoconf semantics, I think having bridges in something like
@rules_cc_autoconf//cmakeor@rules_cc_autoconf//mesonsounds reasonable. However, for the core rules, I would love to keep all of the action runners written in C/C++ to avoid the additional dependency.I don't think I directly answered this but hopefully the context above tells you what you need? I think the most direct answer would be "not opposed but I don't feel the current interfaces are solid enough to bring in more complicated checks before some other high value features are implemented".
abrisco commentedon Apr 11, 2026
I made
conditiona bit more flexible with logical operators. Does #112 unblock anything for you?comicfans commentedon Apr 12, 2026
yes it helped for some simple condition test. my concern is that meson config script do multi definitation in one go(as I shown ) , this usually requires introducing intermediate variable (like ac_cv_sizeof_short_eq_4, ac_cv_sizeof_short_ne_4_and_ac_cv_sizeof_int_eq_4, ac_cv_sizeof_short_ne4_and_ac_cv_sizeof_int_ne_4_and_ac_cv_sizeof_long_eq_4, ac_cv_sizeof_short_ne4_and_ac_cv_sizeof_int_ne_4_and_ac_cv_sizeof_long_ne_4) , or duplicate codes . meson is python alike so I think expose some internal function(#90) , then client can implement the complex part out of core logic, will be easier for my use case. the control flow can also be identical to meson and easier to follow.