Hi Stepan,
* Stepan Kasal wrote on Sat, Jun 04, 2005 at 09:04:17AM CEST:
On Fri, Jun 03, 2005 at 06:40:49PM +0200, Ralf Corsepius wrote:
If I remove caching from AC_CHECK_PROG and AC_CHECK_TOOL, what
_incompatibility_ would it cause?
Would it break some documented behaviour?
Yes,
Hello,
On Fri, Jun 03, 2005 at 06:40:49PM +0200, Ralf Corsepius wrote:
If I remove caching from AC_CHECK_PROG and AC_CHECK_TOOL, what
_incompatibility_ would it cause?
Would it break some documented behaviour?
Yes, caching.
you are right, this is incompatibility.
But I don't think this
Dan Manthey [EMAIL PROTECTED] writes:
It's documented that the builtin `unset' is non-portable, but what about
the use of unset variables vs. empty variables? Is this distinction
always meaningful?
Yes.
Also, I know that ${var:-default} is not portable. Is
${var-default}?
Yes.
For
Hello,
On Thu, Jun 02, 2005 at 11:35:20PM -0700, Paul Eggert wrote:
It's documented that the builtin `unset' is non-portable, but what about
the use of unset variables vs. empty variables? Is this distinction
always meaningful?
Yes.
let me add that the cache uses the distinction
Hello again,
I'm sorry that I post a followup to my own mail:
On Thu, Jun 02, 2005 at 09:04:06PM +0200, Stepan Kasal wrote:
On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote:
No, caching had been invented for faster interaction of several
configure scripts (CONFIG_SUBDIRS) in
On Fri, 2005-06-03 at 09:37 +0200, Stepan Kasal wrote:
Hello again,
I'm sorry that I post a followup to my own mail:
On Thu, Jun 02, 2005 at 09:04:06PM +0200, Stepan Kasal wrote:
On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote:
No, caching had been invented for faster
Hi,
On Fri, Jun 03, 2005 at 02:34:35PM +0200, Ralf Corsepius wrote:
The variable itself has to have higher priority than its cache shadow.
This is how they are supposed to work. Environment variables are
supposed to override the cache.
but in case of programs.m4 this is not the case. Try
On Fri, 2005-06-03 at 16:09 +0200, Stepan Kasal wrote:
Either autoconf should perform a clear cut, that is abandon caches
entirely,
No, I don't want that.
which means autoconf will be totally incompatible to any
former version of autoconf
_incompatible_ ?
If I remove caching from
On Thu, 2 Jun 2005, Paul Eggert wrote:
Dan Manthey [EMAIL PROTECTED] writes:
For that matter, I know you can set bash to error out on $var for an
unset var
Let's not do that, please. Let's stick to traditional behavior
blessed by POSIX. If Bash's behavior is inherited I suppose we
On Fri, 3 Jun 2005, Ralf Corsepius wrote:
Yes, caching.
There exist packages which rely on sharing caches (some intentionally,
some unintentionally), there exist packages which are rely on preset
caches, and finally here is config.site (which I have never used, and
don't actually know how it
On Wed, 2005-06-01 at 13:45 -0400, Dan Manthey wrote:
On Wed, 1 Jun 2005, Ralf Corsepius wrote:
On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
I think the best solution is to drop caching from programs.m4.
Only over my dead body ;-)
Caching was invented mainly for
Hello Dan,
On Wed, Jun 01, 2005 at 01:45:49PM -0400, Dan Manthey wrote:
By the way, note that there seems to be some confusion about whether a
PROG variable is set. `PROG=' does _not_ unset it. How does
AC_CHECK_PROG behave when the variable is set to the empty string?
it usestest x$VAR
Hi Ralf,
On Wed, Jun 01, 2005 at 07:08:08PM +0200, Ralf Corsepius wrote:
On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
Caching was invented mainly for expensive tests which involve
calling a compiler, which can be really slow.
No, caching had been invented for faster interaction of
On Thu, 2 Jun 2005, Stepan Kasal wrote:
it usestest x$VAR = x
Thus the manual should use the term is nonempty, not is set.
(One of the reasons for this behaviour is that unset is not portable.)
It's documented that the builtin `unset' is non-portable, but what about
the use of unset
Hello,
I am trying to put checks for available programs in a
for loop in a configure.ac script.
My first attempt was:
for NAME in cp du mv rm sh su mkdir rmdir bunzip2
bzip2 compress gunzip gzip tar unzip zip
do
AC_PATH_PROG($NAME, $NAME, [no])
done
This does not work, so I wrote
Hello Claudio,
On Wed, Jun 01, 2005 at 07:39:58AM -0700, Claudio Fontana wrote:
for NAME in cp du mv rm sh su mkdir rmdir bunzip2
bzip2 compress gunzip gzip tar unzip zip
do
AC_PATH_PROG($NAME, $NAME, [no])
done
The problem with is that the AC_*PROG macros expect a literal as
a
Stepan Kasal [EMAIL PROTECTED] writes:
I think that the patch which would put AS_VAR_* to programs.m4 would
present a useful general improvement.
Paul, would you accept such a patch?
That sounds good to me, yess.
I think the best solution is to drop caching from programs.m4.
You can also
On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
I think the best solution is to drop caching from programs.m4.
Only over my dead body ;-)
Caching was invented mainly for expensive tests which involve
calling a compiler, which can be really slow.
No, caching had been invented for faster
On Wed, 1 Jun 2005, Ralf Corsepius wrote:
On Wed, 2005-06-01 at 18:33 +0200, Stepan Kasal wrote:
I think the best solution is to drop caching from programs.m4.
Only over my dead body ;-)
Caching was invented mainly for expensive tests which involve
calling a compiler, which can be
19 matches
Mail list logo
