[Ping jyh] Re: [Omake] Should we provide AC_MSG_* and other autoconf-style functions?

[Aleksey Nogin]

On 15.02.2007 21:24, Nathaniel Gray wrote:

>>> I like the idea of more configuration functions, but I'm not so hot on
>>> the autoconf-style names.
>>
>> What naming scheme would you propose?
>>
>> So far I have added the following - AC_MSG_CHECKING AC_MSG_ERROR
>> AC_MSG_FOUND AC_MSG_RESULT AC_MSG_WARN AC_MSG_YES_NO AC_RUN_PROG
>> AC_TRY_COMPILE AC_TRY_LINK AC_TRY_RUN
> 
> I would propose the usual omake convention of camelcase, possibly
> replacing AC with something like Conf:
> 
> ConfChecking, ConfMsgError, ConfMsgFound, etc.

Jason, any thoughts?

Also, should we replace the functions like CheckHeader with a set like
CheckCHeader, CheckCXXHeader, etc, or should we use the autoconf style
of a single "multi-language" test function for every test and a "set
language" function?

>>> Perhaps you could put them in an autoconf.om
>>> compatibility module?
>>
>> Well, they are not that compatible - it's really more
>> autoconf-style/autoconf-inspired.
> 
> If they're not compatible then it's probably a bad idea to keep the
> autoconf names.  It would just lull autoconf-familiar people into a
> false sense of security.
> 
I have some that are compatible - AC_MSG_CHECKING, AC_MSG_RESULT,
AC_MSG_WARN and AC_MSG_ERROR.

I have some that have the same or very similar semantics, but very
different invocation style (in particular, they return a boolean instead
of the autoconf style of supplying the "if yes" and "if no" expressions
as two extra arguments) - AC_TRY_COMPILE, AC_TRY_LINK, AC_TRY_RUN

Some are just using the autoconf-style names - AC_MSG_FOUND,
AC_MSG_YES_NO, and AC_RUN_PROG...

Aleksey