In article <[EMAIL PROTECTED]>, Akim Demaille wrote:
>pushdef([AC_MSG_ERROR],
> [AC_MSG_RESULT([You don't have any C++ compiler, too bad])])
>AC_PROG_CXX
>popdef([AC_MSG_ERROR])
Aha! That's what I was originally after - thanks.
>Olly> There are a lot of macros performing small variations of the
>Olly> same task. It does look like it would benefit from being
>Olly> replaced with a single macro with a clean, flexible interface.
>
>Absolutely. Instead of having several variations, we just need one
>big macros with all bells and whistles. Thanks to m4, this should not
>change anything in the output.
>
>BTW, I've always wanted to work as if we had `which' available: first
>look up for all the candidates, then pick up the first one we like.
>It sounds more like a penalty than anything else, but I expect two
>benefits: some day, on the platform that really have a `which', I
>suppose it will be more efficient than walking by hand with sh
And in fact if we have bash we can use its built-in `type -path'; if
we have tcsh we can use its built-in `which'.
Perhaps the cleanest approach is to write the macro to assume a
working `which'-like command $WHICH, and then supply tcsh and bash
versions, plus a fallback sh version which walks the path as we do at
present. So WHICH might be set to:
/usr/bin/which $PROG
/bin/tcsh -fc "which $PROG"
/usr/local/bin/bash -norc -noprofile -c "type -path $PROG"
../which.sh $PROG
Might even be worth considering including in a perl version if there
are a significant number of systems with perl, but without bash, tcsh,
or /usr/bin/which:
perl -e '$c=shift||die; for (split /:/, $ENV{PATH}) {
if (-x "$_/$c") {print "$_/$c\n";exit}}' $PROG
It would need to be /;/ instead of /:/ on DOS/Windows...
>second, on the weird platforms, such as DOS, I expect `which' to
>handle part of the troubles (such as returning foo.exe for `which
>foo').
Hmm, might do - I don't have a box handy.
>Olly> Do you have a vision of what this might be, or do we need to sit
>Olly> down and look at analyse exactly what each variant does?
>
>IMHO, it should be something like PATH_PROG_WITH_TEST. In particular,
>the fact that we reject some candidates (AC_PATH_PROG IIRC), is
>nothing but a particular test.
OK. And there doesn't seem much point having a "PROG" and a "PROGS"
variant - after all the former is just the latter with a single
element list.
Then there's:
* host-type prefixing (AC_CHECK_TOOL/AC_PATH_TOOL)
Perhaps have an optional argument giving a list of prefixes?
* setting the specified variable to the full path of the result
(AC_PATH_PROG/AC_PATH_PROGS/AC_PATH_TOOL/AC_CHECK_PROGS) vs
setting it to VALUE-IF-FOUND/VALUE-IF-NOT-FOUND (AC_CHECK_PROG).
Simplest to always do the former, and AC_CHECK_PROG can be
implemented on top by passing in "" as VALUE-IF-NOT-FOUND to the
underlying macro, then checking the resulting value of the variable
and fixing it up to the appropriate value passed in.
AC_CHECK_FILE/AC_CHECK_FILES probably don't want to get rolled in (but
perhaps ought to be merged), since they don't use a PATH. They also
can't be implemented with which, since the files checked for needn't
be executable.
Cheers,
Olly
