> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Nov 6, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote:
>> Why not just prefix the reserved autoconf variables with a `_'
>> character?
Alexandre> autoconf used to use just AC_/ac_. Now, it's claiming
Alexandre> ownershi
Thanks for the report, it's a known bug. In fact this bug is not new,
what is new is that the core machinery now correctly catches it.
The problem is related to the fact that AC_PROG_CC can be expanded
twice, and since the first expansion expands AC_PROG_CPP, the second
expansion of AC_PROG_CC w
| I just updated to todays CVS autoconf and now AC_CHECKING seems to be
| broken. The line:
|
| AC_CHECKING(for ZLIB support ...)
|
| results in this configure code:
|
| echo "configure:4389: notice: checking for ZLIB support .." >&5
| echo "checking for ZLIB support .." >&6(for ZLI
| AFAIS, apparent cause are the --?* clauses in autoconf.sh:
|
| > --autoconf-dir | --a* | -A )
| >test $# = 1 && eval "$exit_missing_arg"
| >shift
Yep, I'm in favor of removing all the --a* etc. it makes it uselessly
ambiguous, and short options are a better means to abbrev
First, I've installed m4 version 1.4.
Then i've configured autoconf (run configure tool)
Then i've launched make tha issues the following error :
"Error: Autoconf requires GNU m4 1.1 or later
make: *** [autoconf.m4f] Error 1"
I've made sure the m4 used is the right one (that's to say the one
ins
| First, I've installed m4 version 1.4.
| Then i've configured autoconf (run configure tool)
| Then i've launched make tha issues the following error :
|
| "Error: Autoconf requires GNU m4 1.1 or later
| make: *** [autoconf.m4f] Error 1"
|
| I've made sure the m4 used is the right one (that's t
| Hi,
| With autoconf-2.13, I have been using constructs like the one below
| to detect whether gcc is used:
| [Similar constructs are used in libiberty, libgloss, newlib and
| Cygwin's winsup]
|
| if test $ac_cv_prog_gcc = yes; then
| # do something
| fi
|
| This test relies on the value of ac
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> $ac_cv_c_compiler_gnu() = yes;
Akim> Heck. Thanks for noticing :(
I'm checking in the fix, thanks!
* aclang.m4 (ac_cv_prog_gcc, ac_cv_prog_gxx, ac_cv_prog_g77):
Be AU_DEFUN'd, not AU_ALIAS'd.
Hello!
I'm sorry that I couldn't participate in the discussion earlier, but I
hope it's still not too late.
The purpose of forbidden strings is to provide a certain class of names to
the user that are guaranteed to be expanded by autoconf.
Why do we do it? Whe want to protect the user from over
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Why do we do it? Whe want to protect the user from
Pavel> overquoting. When I was suggesting to protect from underquoting
Pavel> nobody seemed to be enthusiastic about it although it is
Pavel> underquoting that results in truly weir
| AC_INIT(whatever)
| my_ac_builddir_save="`pwd`"
UQA
| cd "$srcdir"
| srcdir="`pwd`"
UQA
| cd "$my_ac_builddir_save"
Useless Quotes Award :)
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> Weird. Doesn't autoconf try to disable (unset) $CDPATH?
It does, and I believe it's knowledge of the various particular cases
is good enough so that you can use `cd "$foo" && pwd`.
On Tue, Nov 07, 2000 at 05:54:42PM +0100, Akim Demaille wrote:
: | cd "$my_ac_builddir_save"
:
: Useless Quotes Award :)
Sure, but useless quotes are better than missing quotes.
I haven't studied the Bourne shell syntax that hard, and
given all the variations over how the so-called Bourne
shell
Thanks for tracking this down. In fact the problem is that I'm not
sure what should be done out of the PROLOGUE in the case of
AC_LANG_PROGRAM(Fortran 77). Maybe you can answer me.
For C for instance, we have:
# AC_LANG_PROGRAM(C)([PROLOGUE], [BODY])
# --
m
Actually in the current case, GNUness should be tested in the
prologue, but in the body, which solves the current issue.
Still, what should we do out of the prologue for
AC_LANG_PROGRAM(Fortran 77)? Still ignore it but warn when it's
nonempty?
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> Sure, but useless quotes are better than missing quotes. I
Lars> haven't studied the Bourne shell syntax that hard, and given all
Lars> the variations over how the so-called Bourne shell compatible
Lars> shells behave, I've taken the b
On Tue, Nov 07, 2000 at 06:09:45PM +0100, Akim Demaille wrote:
: absolute="`cd "$relative" && pwd`"
:
: is not portable, and nor is
:
: absolute="`cd \"$relative\" && pwd`"
That the first line is not portable comes as no surprise.
That the second one isn't - I find obscene...
: You don't have
| On Tue, Nov 07, 2000 at 06:09:45PM +0100, Akim Demaille wrote:
| : absolute="`cd "$relative" && pwd`"
| :
| : is not portable, and nor is
| :
| : absolute="`cd \"$relative\" && pwd`"
|
| That the first line is not portable comes as no surprise.
| That the second one isn't - I find obscene...
On 7 Nov 2000, Akim Demaille wrote:
> > "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
>
> Lars> Weird. Doesn't autoconf try to disable (unset) $CDPATH?
>
> It does, and I believe it's knowledge of the various particular cases
> is good enough so that you can use `cd "$foo" && pwd`.
tha
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> On 7 Nov 2000, Akim Demaille wrote:
>> > "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
>>
Lars> Weird. Doesn't autoconf try to disable (unset) $CDPATH?
>> It does, and I believe it's knowledge of the various particular
Hello, Akim!
> The one and only approach is the current one. Let's stop reinventing
> the wheel.
That's probably too stronly worded :-)
> Pavel> Another question is the namespace. I agree that Autoconf
> Pavel> shouldn't be so greedy. One name per package should be the
> Pavel> right way. I.e.
Akim Demaille wrote:
> but for Fortran 77, $1 was ignored :(
>
> # AC_LANG_PROGRAM(Fortran 77)([PROLOGUE], [BODY])
> # ---
> # Yes, we discard the PROLOGUE.
> m4_define([AC_LANG_PROGRAM(Fortran 77)],
> [ program main
> $2
> end])
> So, what s
Hello, Raja!
> AC_LANG_SOURCE(C++) uses
>
> extern "C" void exit (int);
I remember we already discussed it. I believe that there are many issues
here.
1) "return" is rumored to be unportable/unreliable, but does it apply to
C++? I doubt it. It's probably better to use "return" for C++.
2)
Hi,
Pavel Roskin <[EMAIL PROTECTED]> writes:
> Hello, Raja!
> > AC_LANG_SOURCE(C++) uses
> >
> > extern "C" void exit (int);
>
> I remember we already discussed it. I believe that there are many issues
> here.
>
> 1) "return" is rumored to be unportable/unreliable, but does it apply to
> C+
Hello, Akim!
> > $ac_cv_c_compiler_gnu() = yes;
>
> Akim> Heck. Thanks for noticing :(
>
> I'm checking in the fix, thanks!
>
> * aclang.m4 (ac_cv_prog_gcc, ac_cv_prog_gxx, ac_cv_prog_g77):
> Be AU_DEFUN'd, not AU_ALIAS'd.
I'm afraid you are fixing the symptoms, not the cause
Hello, Lars!
> > Bad news: the native make doesn't work - it cannot create "autoconf" and
> > other scripts because they have both explicit and suffix rules:
> [...]
>
> BSD makes in their current form suck outright. Many of them don't even
> pass variables down to sub-makes. This is the main
On Nov 7, 2000, Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Hello, Akim!
>> > $ac_cv_c_compiler_gnu() = yes;
>>
Akim> Heck. Thanks for noticing :(
>>
>> I'm checking in the fix, thanks!
>>
>> * aclang.m4 (ac_cv_prog_gcc, ac_cv_prog_gxx, ac_cv_prog_g77):
>> Be AU_DEFUN'd, not AU_ALIAS'd.
> I'm
On Nov 7, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Yep, I'm in favor of removing all the --a* etc. it makes it uselessly
> ambiguous, and short options are a better means to abbreviate. And
> trying to support exact abbreviations, as is done in configure, is an
> additional tedious main
--- Akim Demaille <[EMAIL PROTECTED]> wrote:
> > "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> Alexandre> On Nov 6, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote:
> >> Why not just prefix the reserved autoconf variables with a `_'
> >> character?
>
> Alexandre> autoconf used t
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
Earnie> But, neither of you answered my question. Why not use `_' to
Earnie> prefix A?_* names? You can then declare that the user is
Earnie> incorrect as _A?_* is a vendor variable! I as a user should
Earnie> be allowed to declare A?_
30 matches
Mail list logo
