Re: Check directory arguments for consistency

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

 



-----BEGIN PGP SIGNED MESSAGE-----
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:
> 
> # AC_DIR_ARG_CONSISTENT(DIR_ARG [, FAILED_OPTION])
> # ------------------------------
> # 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])
> #
> AC_DEFUN([AC_DIR_ARG_CONSISTENT],
> [
> 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):
http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING

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             ebb9@xxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpWvAgACgkQ84KuGfSFAYD5WgCgkXwZKow83niC2kPCNWIaaypq
OrUAoJXmApgezO8i/yOMlBd0m5xO1B+r
=GxPN
-----END PGP SIGNATURE-----


_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux