[Top][All Lists]

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

Re: Check directory arguments for consistency

From: Eric Blake
Subject: Re: Check directory arguments for consistency
Date: Thu, 09 Jul 2009 21:56:56 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090605 Thunderbird/ Mnenhy/

Hash: SHA1

According to Christian Rössel on 5/18/2009 8:17 AM:

Hello Christian, and sorry for the delay in replying,

> I pulled the code out of general.m4 and defined the following macro:
> # ------------------------------
> # Check directory argument DIR_ARG for consistency, i.e. remove trailing
> # slashes and abort if argument is not an absolute directory name. Use
> # FAILED_OPTION to show the user which option caused an error,  e.g.
> # AC_DIR_ARG_CONSISTENT([doxygen_output_dir], [--with-doxygen-output-dir])
> #
> [
> for ac_var in $1
> do
>   eval ac_val=\$$ac_var

I'd consider using some of the m4sh macros here (AS_FOR or AS_VAR_SET
might be helpful).

>   # Remove trailing slashes.
>   case $ac_val in
>     */ )
>       ac_val=`expr "X$ac_val" : 'X\(.*[[^/]]\)' \| "X$ac_val" : 'X\(.*\)'`
>       eval $ac_var=\$ac_val;;
>   esac
>   # Be sure to have absolute directory names.
>   case $ac_val in
>     [[\\/$]]* | ?:[[\\/]]* )  continue;;
>     NONE | '' ) case $ac_var in *prefix ) continue;; esac;;
>   esac
>   if test $# -gt 1; then

Is this intended to be the shell's $# or m4's $#?  If m4, then you should
use m4_if to only output the branch of the conditional that matters,
rather than wasting space on a shell conditional that will always take the
same path.

>     AC_MSG_ERROR([expected an absolute directory name for $2: $ac_val])
>   else
>     AC_MSG_ERROR([expected an absolute directory name for --$ac_var:
> $ac_val])
>   fi
> done
> ])
> You can also use this as a replacement for the hard coded consistency
> check in general.m4, just call it in this way
> AC_DIR_ARG_CONSISTENT([exec_prefix prefix bindir ...])
> without the second parameter. If you consider this useful and meeting
> the autoconf stnadards, please give me some hint for creating a patch.
> Which autoconf should I use as base? Currently I'm working with a 2.63
> tarball, not with git. Should the new macro placed in general.m4?

The best approach is to submit the patch against the master branch of
autoconf.git.  There are some helpful hints for using git here (although
some of that file documents conventions particular to coreutils but not
shared in autoconf):

As for location, it does look like it would fit in general.m4, close to
the code that you are factoring into the new macro.  Also, we have to be
careful as to whether you will be needing copyright assignment, or whether
this is a trivial enough change.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

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