allow more flexible condition evaluation

[comicfans]

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

[comicfans]

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

macros.AC_DEFINE_EXPR(["gint32","gint32_modifier","gint32_format","guint32_format", "guint32_align"],expr = '''
if ac_cv_sizeof_short == 4:
    gint32 = 'short'
    gint32_modifier='"h"'
    gint32_format='"hi"'
    guint32_format='"hu"'
    guint32_align = short_align
elif ac_cv_sizeof_int == 4:
    gint32 = 'int'
    gint32_modifier='""'
    gint32_format='"i"'
    guint32_format='"u"'
    guint32_align = ALIGNOF_INT 
elif ac_cv_sizeof_long == 4:
    gint32 = 'long'
    gint32_modifier='"l"'
    gint32_format='"li"'
    guint32_format='"lu"'
    guint32_align = ALIGNOF_LONG
else:
    assert False, 'Compiler provides no native 32-bit integer type'
''',
                                                                                                                 requires = ["ac_cv_sizeof_short",
"ac_cv_sizeof_int", "ac_cv_sizeof_long", "ALIGNOF_INT"])

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]

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//cmake or @rules_cc_autoconf//meson sounds 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’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 ?

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]

I made condition a bit more flexible with logical operators. Does #112 unblock anything for you?

[comicfans]

I made condition a bit more flexible with logical operators. Does #112 unblock anything for you?

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.