[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: overriding autoconf macros (was: autoconf 2.64 warning: AC_REQUIRE:
From: |
Diego Saravia |
Subject: |
Re: overriding autoconf macros (was: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required) |
Date: |
Sat, 16 Jan 2010 11:55:01 -0300 |
> If you override the definition of an autoconf macro, then the maintenance
> burden is shifted away from autoconf onto your shoulders. If it works for
> you, great. But if autoconf changes for the next release, and upgrading
> autoconf then breaks your override (and that has been known to happen), we
> don't have any sympathy, because it was not our fault that you did an
> override.
>
I agree
> Maybe the better thing to do is take a step back, and tell us what you are
> really trying to accomplish, and why you felt that your override was
> necessary. If we agree, then we can fix it upstream, or perhaps we can
> suggest a better idiom that accomplishes your same goal without requiring
> you to do an override.
ok, thank you, for your atention
>
> That sentence was hard to parse. If I understood correctly, you are
> trying to make it so that if a person lacks a compiler, but runs
> ./configure, that ./configure will attempt to install the compiler on the
> user's behalf, rather than flat out dying with an error.
>
yes, but these is not done by configure
configure only writes a file "./lacks" telling another program what
projects my system is lacking
> Unfortunately, there is no way to portably install a compiler. Having a
> configure script attempt to do a non-portable installation of a compiler
> goes against the philosophy of autoconf.
yes, is not a job for autoconf, I agree, but if configure writes a
lacks file it will not hurt anyone.
> Rather, it is a sane assumption,
> and documented in the default INSTALL file that many projects borrow from
> autoconf, that a user attempting to build a package from source can
> already be expected to have a working compiler. It is not configure's job
> to make up for users that can't meet the prerequisites.
ok, but configure could help us in that problem, cc is obvious, but
another projects no.
##################################################################3
>> I changed AC_MSG_FAILURE, --it is used by AC_PROG_CC*--, locating this:
> Changed it how? The discussion would be a lot easier if you showed us
> your replacement, so we could see in code what you are trying to describe
> in English.
I added code to an m4 file in the m4 directory in the source code of
the project:
m4_define([AC_MSG_FAILURE],
[{ AS_MESSAGE([error: in `$ac_pwd': See `config.log' for more details: [$1]], 2)
AC_MSG_NOTICE([$1])
#, [$2]);
}])
original code is located in general.m4 in autoconf distributed files
m4_define([AC_MSG_FAILURE],
[{ AS_MESSAGE([error: in `$ac_pwd':], 2)
AC_MSG_ERROR([$1
See `config.log' for more details.], [$2]); }])
So I am changing ERROR for NOTICE
What I think could be a better way is to put a YES|NO variable in
each TEST provide by autoconf, for example
AC_PROG_CC
in one case configure will stop if it do not found a program it needs
in other case it will inform the fact and continue until it finish,
telling us at once all the programs its needs.
By now I am puting in my configure.ac a macro:
TEST_PACKS([subversion wget xz texinfo tar cc ranlib ar ld strip latex
tgif latex2html emacs muse-el dvips ])
this macro is expanded to individual test of each program
AC_DEFUN([TEST_PACKS],[
for dep in [$1]; do
echo Package: ${dep}
TEST_PACK([${dep}])
done
#echo NEEDS-LACKS: $FALTA - $NECESITA
###########################################$FALTA is filled up in
individual tests (must put in english)
echo $FALTA|tr ':' '\n' >lacks
echo $NECESITA|tr ':' '\n' >needs
])
AC_DEFUN([PROG_DEP],[
#depends
if test "x${NECESITA}" = "x"; then
NECESITA=[$1]
else
NECESITA=${NECESITA}:[$1]
fi
AC_MSG_NOTICE([Depends on:[$1]]);
])
####################################################################################################
AC_DEFUN([PROG_ALERT],[
# ejecutable, paquete
#lacks
if test "x${FALTA}" = "x"; then
FALTA=[$1]
else
FALTA=${FALTA}:[$1]
fi
AC_MSG_NOTICE([Needs:[$1]]);
])
# I dont figure out yet how to call macros using variables in the names.
AC_DEFUN([TEST_PACK],[
case [$1] in
cc)
TEST_PROG_CC
;;
lex)
TEST_PROG_LEX
;;
fortran)
TEST_PROG_FORTRAN
;;
ranlib)
TEST_PROG_RANLIB
;;
etc
AC_DEFUN([PROG_FIND],[
# variable, archivo ejecutable, paquete generico
AC_PATH_PROGS([$1], [$2],no,[${PATH}:/usr/local/bin])
PROG_DEP([$3])
if test "x$[$1]" = "xno" -o ! -x "$[$1]"; then
AC_MSG_WARN([No encuentro [$2] del paquete generico [$3]]);
PROG_ALERT([$3])
fi
])
AC_DEFUN([TEST_PROG_WGET],[
#PROG_WGET
PROG_FIND([WGET],[wget],[wget])
])
AC_DEFUN([TEST_PROG_CC],[
AC_PROG_CC
PROG_DEP([cc])
if test "x$CC" = "x"; then
PROG_ALERT([cc])
])
> --
> Don't work too hard, make some time for fun as well!
>
> Eric Blake address@hidden
>
>
--
Diego Saravia
address@hidden
NO FUNCIONA->address@hidden
- autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required, Carsten Heinrici, 2010/01/10
- Re: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required, Eric Blake, 2010/01/11
- Re: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required, Carsten Heinrici, 2010/01/16
- Re: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required, Eric Blake, 2010/01/16
- Re: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required, Diego Saravia, 2010/01/16
- overriding autoconf macros (was: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required), Eric Blake, 2010/01/16
- Re: overriding autoconf macros (was: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required),
Diego Saravia <=
- Re: overriding autoconf macros (was: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required), Diego Saravia, 2010/01/16
- Re: overriding autoconf macros, Peter Johansson, 2010/01/16
- Message not available
- Re: overriding autoconf macros, Diego Saravia, 2010/01/17