Edit

kc3-lang/automake/m4/auxdir.m4

Branch :

  • Show log

    Commit

  • Author : Alexandre Duret-Lutz
    Date : 2003-08-24 19:56:07
    Hash : 9e9f7974
    Message : * configure.in: Require Autoconf 2.57b to be sure aclocal can use autom4te --language Autoconf-without-aclocal-m4. * m4/init.m4: Likewise. Move the AC_PREREQ and m4_pattern_allow calls inside the AM_INIT_AUTOMAKE macro. * m4/auxdir.m4, m4/cond.m4, m4/lex.m4, m4/regex.m4: Move AC_PREREQ calls inside the macros. * m4/header.m4: Remove AC_PREREQ.

  • m4/auxdir.m4
  • # AM_AUX_DIR_EXPAND
    
    # Copyright (C) 2001, 2003 Free Software Foundation, Inc.
    
    # This program is free software; you can redistribute it and/or modify
    # it under the terms of the GNU General Public License as published by
    # the Free Software Foundation; either version 2, or (at your option)
    # any later version.
    
    # This program is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    # GNU General Public License for more details.
    
    # You should have received a copy of the GNU General Public License
    # along with this program; if not, write to the Free Software
    # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
    # 02111-1307, USA.
    
    # For projects using AC_CONFIG_AUX_DIR([foo]), Autoconf sets
    # $ac_aux_dir to `$srcdir/foo'.  In other projects, it is set to
    # `$srcdir', `$srcdir/..', or `$srcdir/../..'.
    #
    # Of course, Automake must honor this variable whenever it calls a
    # tool from the auxiliary directory.  The problem is that $srcdir (and
    # therefore $ac_aux_dir as well) can be either absolute or relative,
    # depending on how configure is run.  This is pretty annoying, since
    # it makes $ac_aux_dir quite unusable in subdirectories: in the top
    # source directory, any form will work fine, but in subdirectories a
    # relative path needs to be adjusted first.
    #
    # $ac_aux_dir/missing
    #    fails when called from a subdirectory if $ac_aux_dir is relative
    # $top_srcdir/$ac_aux_dir/missing
    #    fails if $ac_aux_dir is absolute,
    #    fails when called from a subdirectory in a VPATH build with
    #          a relative $ac_aux_dir
    #
    # The reason of the latter failure is that $top_srcdir and $ac_aux_dir
    # are both prefixed by $srcdir.  In an in-source build this is usually
    # harmless because $srcdir is `.', but things will broke when you
    # start a VPATH build or use an absolute $srcdir.
    #
    # So we could use something similar to $top_srcdir/$ac_aux_dir/missing,
    # iff we strip the leading $srcdir from $ac_aux_dir.  That would be:
    #   am_aux_dir='\$(top_srcdir)/'`expr "$ac_aux_dir" : "$srcdir//*\(.*\)"`
    # and then we would define $MISSING as
    #   MISSING="\${SHELL} $am_aux_dir/missing"
    # This will work as long as MISSING is not called from configure, because
    # unfortunately $(top_srcdir) has no meaning in configure.
    # However there are other variables, like CC, which are often used in
    # configure, and could therefore not use this "fixed" $ac_aux_dir.
    #
    # Another solution, used here, is to always expand $ac_aux_dir to an
    # absolute PATH.  The drawback is that using absolute paths prevent a
    # configured tree to be moved without reconfiguration.
    
    AC_DEFUN([AM_AUX_DIR_EXPAND],
    [dnl Rely on autoconf to set up CDPATH properly.
    AC_PREREQ([2.50])dnl
    # expand $ac_aux_dir to an absolute path
    am_aux_dir=`cd $ac_aux_dir && pwd`
    ])