[PATCH] m4: provide additional pkg-config macros

[Dan Nicholson]

On 5/8/12, Luca Barbato <lu_zero at gentoo.org> wrote:
> On 08/05/12 14:14, Dan Nicholson wrote:
>> Overall I like these a lot once you explained what they did. I just
>> want to make sure we get the interface right before it goes into the
>> public macros.
>
> Sure
>
>>> +AS_CASE([$AS_TR_SH([with_]with_arg)],
>>> +            [yes],[PKG_CHECK_MODULES([$1],[$2],$3,$4)],
>>
>> Is it problematic to not quote $3/$4? In my experience, people will
>> want to put multiline commands in these arguments and autoconf can get
>> easily screwed up without the quotes. I believe m4_default in
>> PKG_CHECK_MODULES will continue to use the fallback even if $3/$4 are
>> quoted empty strings.
>
> I remember I did that for a specific reason, but currently I'm not sure
> which it was.

Can you check if quoting them changes anything? I just made a straight
wrapper around PKG_CHECK_MODULES with [] quotes around all args and it
handles any which way I use the $3/$4 args.

>> Not exactly. AM_CONDITIONAL turns this into HAVE_$var_TRUE/FALSE.
>> Better to say this creates an automake conditional named
>> HAVE_[VARIABLE-PREFIX]. That's how the automake documentation
>> describes it.
>
> According
> http://www.gnu.org/software/automake/manual/html_node/Usage-of-Conditionals.html
> it seems to do what I meant.

You deleted what you had, but I took it to mean that you would get a
_make_ variable called HAVE_$var. That's not the same thing as an
automake conditional. Not a big deal, though.

>>> +#
>>> +# --------------------------------------------------------------
>>> +AC_DEFUN([PKG_HAVE_WITH_MODULES],
>>
>> This might need a better name. Maybe PKG_WITH_MODULES_CONDITIONAL to
>> signify you're creating an AM_CONDITIONAL?
>
> I prefer having terse names.

OK, well this is going into public API now, so I think non-terse names
would be better. I suggest:

PKG_CHECK_WITH_MODULES
PKG_CHECK_WITH_MODULES_CONDITIONAL
PKG_CHECK_WITH_MODULES_DEFINE

>>> +[
>>> +PKG_WITH_MODULES([$1],[$2],,,[$3],[$4])
>>
>> Why not pass all the same arguments as PKG_WITH_MODULES?
>
> Because the macro is meant to have a stock behavior, if an override is
> needed you are already adding it there.

I'm sorry, I didn't follow this. Where is the override being added?

>>> +
>>> +AM_CONDITIONAL([HAVE_][$1],
>>> +               [test "$AS_TR_SH([with_]m4_tolower([$1]))" = "yes"])
>>> +])
>>> +
>>> +# PKG_HAVE_DEFINE_WITH_MODULES(VARIABLE-PREFIX, MODULES,
>>> +#                              [DESCRIPTION], [DEFAULT])
>>> +#
>>> +# Convenience macro to run AM_CONDITIONAL and AC_DEFINE after
>>> +# PKG_WITH_MODULES check.
>>> +#
>>> +# HAVE_[VARIABLE-PREFIX] is exported as make and preprocessor variable.
>>
>> exported as an automake conditional and preprocessor macro.
>
> The wording is surely better.
>
>>
>>> +#
>>> +# --------------------------------------------------------------
>>> +AC_DEFUN([PKG_HAVE_DEFINE_WITH_MODULES],
>>
>> Again, I'm not so sure about the name.
>> PKG_WITH_MODULES_DEFINE_CONDITIONAL? Kind of a mouthful. I do prefer
>> to have the extra action as an addendum to the base name, though.
>>
>>> +[
>>> +PKG_HAVE_WITH_MODULES([$1],[$2],[$3],[$4])
>>
>> Same as above, any reason not to pass all the arguments through to
>> PKG_WITH_MODULES?
>
> Same as above, I prefer terse names and those two macros are meant to
> not have overrides (the generic one is here to cover that need, the
> other two are what I ended up using about all the time).

Surely you could just add ",," to your call, though? I don't see any
reason not to transfer the flexibility through to these variants.

--
Dan