[this is enough of an independent question that it probably would have
been better to start a new thread]
According to Diego Saravia on 1/16/2010 7:02 AM:
>> Correct - you can't change AC_PROG_CC (well, you can, by patching
>> autoconf, but then everyone else running unpatched autoconf can't build
>> your package; or you could redefine AC_PROG_CC, but that gets hairy to
>> maintain). But you CAN change FOO, since it was FOO that had the problem
>> in the first place.
>
>
> I changed AC_MSG_FAILURE, --it is used by AC_PROG_CC*--, locating this:
>
> m4_define([AC_MSG_FAILURE],
> [{ AS_MESSAGE([error: in `$ac_pwd': See `config.log' for more details: [$1]], 2)
> AC_MSG_NOTICE([$1])
> #, [$2]);
> }])
>
>
> in a m4 file under /m4 in a project
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.
>
> it seems that is working. is a correct way? # ok perhaps
> AC_MSG:FAILURE needs to act its original way in another errors, but
> ...
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.
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.
> * I am trying to setup a system that provides a file with all building
> dependecies that the system is lacking, so I can install them in an
> automatic form, and AC_PROG_CC and others stops the system giving
> errors, so I am trying to change that behavior or error policy.
>
>
> If fou don' t have the system, stoping configure its ok, you lacks cc,
> its an error, human intervention is needed, but I you have that
> system, the system installs a cc so, it is not an error, is only a
> situation that the system must handle.
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.
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. 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.
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@xxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
