[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About dynamic configure options.

From: Eduardo Costa
Subject: Re: About dynamic configure options.
Date: Thu, 13 Dec 2012 22:22:55 +0000

Thanks guys,

I actually sent a "solution" much like yours Nick. Don't know why
Stefano didn't send my answer. This is what I came up with:

[m4_divert_text([HELP_CANON], [_ACEOF
echo -en "\n* --option=VAL            Date: `date`"
cat <<\_ACEOF])])


You can see automake's archives for my whole message.

Te code above will get hooked at the end of `HELP_CANON' (before the
`heredoc' ends), or after the `Fine tuning' options if canonical
support macros hasn't been called.

Something that did surprise by looking at `general.m4' is that
sections such as HELP_CANON, HELP_BEGIN, etc, have all been allocated
sequentially, leaving no room for per-project customization.

This is just my ignorant's opinion. I'm far from being a m4, autoconf,
or automake specialist.


On 13/12/2012, Nick Bowler <address@hidden> wrote:
> On 2012-12-13 10:20 -0700, Eric Blake wrote:
>> On 12/13/2012 05:58 AM, Stefano Lattarini wrote:
>> > On 12/11/2012 12:57 AM, Eduardo Costa wrote:
>> >> Is it possible at all to have a configure option whose help message can
>> >> expand a
>> >> variable, or can otherwise accept the output of a command at
>> >> configure-time?
>> >>
>> >> For example, imagine this as part of the output of `./configure':
>> >>
>> >> --with-user=user        Who to complain to (default X)
>> >>
>> >> Where X could be, say, the output of the command `whoami'.
>> >>
>> >> This might be done by usual means (couldn't do it) or just with some
>> >> trickery to to inject the string manually at the end of some section
>> >> (say HELP_CANON or other), and giving the output of the command on a
>> >> new line, so it doesn't get inside the `cat << LABEL ... LABEL'
>> >> constructs that seem to be used to output options and help messages.
>> Unfortunately, it looks like the current setup of autoconf is pretty
>> hard-coded to constant strings determined at m4-time; making it use
>> shell variables for dynamic output would require quite a bit of patching
>> (maybe by introducing new macros such as AC_ARG_WITH_UNQUOTED, to take
>> care of the tweaks needed to close the quoted heredoc, open an unquoted
>> heredoc to do the substitution, then reopen the quoted heredoc for the
>> rest of the script).  It sounds like a useful request, though.
> FWIW it's not too hard to hack it:
>   AC_ARG_WITH([user], [_ACEOF
>     # Eschew error handling!
>     me=`whoami`
>     cat <<EOF dnl
>     m4_newline([AS_HELP_STRING([--with-user],
>                                [Who to complain to (default $me)])])dnl
>     m4_newline([EOF])
>     cat <<\_ACEOF])
> but that is, of course, relying on internal details of how Autoconf
> generates the code to produce --help output.  But there remain other
> problems: firstly, the --help text appears quite early in the configure
> output -- much earlier than the position of AC_ARG_WITH in
> would imply.  This may make it hard to put anything useful in the help
> text, without computing it directly in AC_ARG_WITH_UNQUOTED or whatever
> (as done in the above example).
> Secondly, regarding this specific example, I don't know if whoami is
> universally available.  So determining the default username is probably
> within the realm of a "full" configure test, with at least one invocation
> of AC_CHECK_PROGS.  Such a test is almost certainly too much to do before
> printing --help output.
> Normally it is sufficient to just write the --help text as a static
> string explaining how the default is determined.  In the case of a
> username like above, I would probably do something like:
>   --with-user=user        Who to complain to (default: current user)
> and then make the configure script print a line such as:
>   Checking which user will receive complaints... nbowler
> Cheers,
> --
> Nick Bowler, Elliptic Technologies (

reply via email to

[Prev in Thread] Current Thread [Next in Thread]