ments that are too long,
| when using implementations of `expr' that fail if the matched string
| is longer 128 bytes or longer.
Sorry for the delays. I chose the `expr' one. Here is what I am
committing now:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* aut
> "Bernard" == Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
Bernard>The other one is the test for macro AC_FUNC_STRTOD; in
Bernard> fact the macro runs OK saying that 'strtod()' is broken on
Bernard> this machine and that 'pow()' is in libm.a (I don't know why
Bernard> we test for p
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> Could the really annoying "feature" of mangling the subjects of
Russ> incoming messages be turned off?
It should be ok by now.
___
Autoconf mailing list
[EMAIL PROTECTED]
http://mail.gnu.or
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Woah!!! Didn't make much sense on the first scan through. I'll
Gary> read it more carefully later this evening.
Good! It's a write once read never piece of text :)
___
Autoconf mailing
> "Martin" == Martin Wilck <[EMAIL PROTECTED]> writes:
Martin> I wonder why autoconf doesn't use shell functions. Is that a
Martin> compatibility issue? According to the bash info pages, shell
Martin> functions belong to the POSIX standard for the Bourne shell.
You are twice right, but the
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello, Akim!
>> You may fall on some lonely hermit who decided plain old
>> functionless sh was enough for him, but then 1. he is certainly not
>> interested in your scripts, or 2. if he wants them, let him install
>> bash.
Pavel>
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello! What version of Automake are we using to rebuild
Pavel> Makefile.in's?
Pavel> It must be a modified version since the stock Automake
Pavel> hardcodes "gtar" and has a bug in the "distdir" target.
I use ``stock'' Automake 1
Hi People,
We are heading slowly towards the 2.50 release. There are still many
small details to fix in Autoconf, in particular the test suite which
Pavel is quickly improving. I think it is reasonable to aim at 2.49b,
a widely advertised beta, for the next couple of weeks.
Before 2.50, it wo
| On Thu, Sep 21, 2000 at 08:17:18AM -0700, Ossama Othman wrote:
| : On Thu, Sep 21, 2000 at 02:56:07PM +0200, Peter Eisentraut wrote:
| : > Akim Demaille writes:
| : >
| : > > >>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
| : > >
| :
| Hello!
| I tried to run autoupdate on the following configure.in
|
| AC_INIT
| AC_LINK_FILES(a, b)
| AC_OUTPUT
Thanks Pavel, I'll try that.
| and it printed:
|
| /tmp/au9096/input.m4:45: /usr/bin/m4: Non-numeric argument to built-in `0@0@h'
| /tmp/au9096/input.m4:45: /usr/bin/m4: Cannot ope
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
Earnie> --- Ossama Othman <[EMAIL PROTECTED]> wrote:
>> Out of curiosity, are you guys receiving duplicate e-mails from the
>> list? I seem to be getting two copies of each e-mail sent from all
>> of the GNU lists I'm subscribed to.
>>
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello! Unless there are any serious reasons or deadlines
Pavel> imposed on the maintainers please don't release Autoconf-2.50
Pavel> in September.
Pavel> The mailing lists at gnu.org are still out of order, so if
Pavel> anybody ha
| Hello!
| Run this:
|
| TMPDIR=. autoupdate --debug /dev/null
| echo AC_INIT >configure.in
| grep -v ^_ au*/au.txt >>configure.in
| autoupdate
Brilliant!
| The result is truly scary. There are two AC_INIT's, four AC_DIAGNOSE's,
| one AC_REQUIRE outside macro definition, even one AC_C_CROSS!
| On Sep 21, 2000, "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
| > * autoconf.sh: Report full macro name for missing macros.
|
| Ok, except that
|
| > - match (\$0, /($pattern)[_A-Za-z0-9]*/)
| > + match (\$0, /([_A-Za-z0-9]*($pattern)[_A-Za-z0-9]*)/)
|
000-10-02 Morten Eriksen <[EMAIL PROTECTED]>
| +
| + * aclang.m4 (AC_LANG_SOURCE(C++)): don't define exit(), it'll
| + mismatch with the native exit() definition on some platforms
| + (happens at least with g++ 2.96 and glibc 2.1.92 on Red Hat Linux
| + v7).
| +
| 20
| On Tue, Oct 03, 2000 at 01:04:12PM +0200, Morten Eriksen wrote:
| : Akim Demaille <[EMAIL PROTECTED]> writes:
| : > | define([AC_LANG_SOURCE(C++)],
| : > | [#line __oline__ "configure"
| : > | #include "confdefs.h"
| : > | -#ifdef __cplusp
| Akim Demaille <[EMAIL PROTECTED]> writes:
| > | Index: aclang.m4
| > | ===
| > | RCS file: /cvs/autoconf/aclang.m4,v
| > | retrieving revision 1.68
| > | diff -u -r1.68 aclang.m4
| > | --- aclang.m4
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Oct 2, 2000, Morten Eriksen <[EMAIL PROTECTED]> wrote:
>> * aclang.m4 (AC_LANG_SOURCE(C++)): don't define exit(), it'll
>> mismatch with the native exit() definition on some platforms
>> (happens at least with g++ 2.96
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Why can't I use AC_CHECK_FILE when cross-compiling? If I need
Peter> to look for a file that is used during the build then that has
Peter> nothing to do with what the compiler does.
Then just don't use it :) I don't understan
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello, Akim!
Hi there!
> Why can't I use AC_CHECK_FILE when cross-compiling? If I need
> to look for a file that is used during the build then that has
> nothing to do with what the compiler does.
Pavel> I agree, this limitation
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> For example, I need to find the modular DocBook stylesheets to
Peter> build the documentation of a package. The found file will be
Peter> passed on the command line to jade. Now this macros tells me
Peter> that I can't build m
| > autoconf: Undefined macros:
| > ***BUG in Autoconf--please report*** AC_FD_CC
| > ***BUG in Autoconf--please report*** AC_FD_CC
| > ***BUG in Autoconf--please report*** AC_FD_CC
| > configure.in:2:AC_CHECK_TOTO
|
| That's not really helpful, I know.
And in fact most of
| The obvious reason for this behavior is that AC_PROG_CC requires
| AC_PROG_CPP to run before the AC_PROG_CC macro body. This will then
| pick up the gcc compiler (if present) and then use the cached value
| for CC, no matter which compilers we specify for AC_PROG_CC.
|
| Any suggestions on how
>>>>> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Akim Demaille writes:
>> Anyway, I am still against the possibility to specify a list of
>> compilers for AC_PROG_CC, CXX etc. I think we will never stop
>> having problem wi
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Oct 9, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Currently I can't think of any good one. In addition, I now think
>> it is now feasible to merge *_C
The problem is that:
/tmp % ace --trace AC_PROG_CC
autoconf: warning: --macrodir is obsolete, use --autoconf-dir
configure.in:2:AC_PROG_CC:foo bar supercompiler
configure.in:2:AC_PROG_CC:
someone is requiring AC_PROG_CC *inside* the AC_PROG_CC itself. But
since AC_PROG_CC (the first one) is in
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> To be strict, the testsuite doesn't guarantee it because macros
Pavel> can expand differently dependent e.g. on the number of
Pavel> arguments.
I agree.
Pavel> Anyway, I agree with your decision.
I agree too :)
Pavel> I can, b
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
Morten> The particular challenge I just bumped into is how to let
Morten> Autoconf configure know about a "self-made compiler", in the
Morten> sense that I have written a wrapper script around the MSVC++
Morten> cl.exe compiler (to let
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
Morten> One argument for using the output of uname in some form
Morten> instead of the current scheme is that the Cygwin test (at
Morten> least) will fail if not using GCC as the compiler. I'm using
Morten> MSVC++ cl.exe now, and the Cy
| configure.in:
| ...
| : ${CC-my_super_script_CC}
Sorry, I meant:
: ${CC=my_super_script_CC}
| AC_PROG_CC
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> I don't much care how many features you add if the old
Thomas> configure.in scripts do not work properly. (When is 2.49b
Thomas> coming out so we can see if some of the bugs are fixed?)
It should happen RSN. The problem is t
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> Please take a moment to release stable and compatible versions of
Bob> Autoconf, Automake, and Libtool so that there is a new baseline
Bob> for us users.
Rest reassured: we don't plan to release a buggy Autoconf. Libtool is
in go
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Akim> I think we will never stop having problem with this feature :(
Pavel> Don't be pessimistic. We haven't tried it hard yet.
You're not a Jedi yet, soon you'll be attracted by the dark side.
Then you'll be a real Autoconf maintainer :
| It was also mentioned on the list a while ago (by yours truly) how the
| _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses
| AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT.
AFAICS you still have this problem: you use AC_LINK_IFELSE. You
shouldn't, rather, see how
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Actually, cvs libtool is still much happier with autoconf-2.13
Gary> than cvs autoconf =(O| I am hoping that a 2.50 compatible
Gary> libtool-1.4 won't be too far behind the autoconf release...
What's wrong? How does it happen? Wh
| * Morten
| | It was also mentioned on the list a while ago (by yours truly) how the
| | _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses
| | AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT.
|
| * Akim
| | AFAICS you still have this problem: you use AC_LINK_IFELSE.
| * Akim
| | [...] Your patch, as is, does not solve [...]
|
| I know, I know. I don't claim the patch to be perfect, I'm just saying
| that it is _better_ than the code it replaces. :^}
|
| | [...] since AC_PROG_CC launches AC_EXEEXT which uses AC_LINK_IFELSE
| | which requires AC_PROG_CC, au
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> Note that the above described "-e" option is a completely
Lars> different option from the "-ef" option. When finding the
Lars> exeext, I also believe it is unproblematic to do so on the build
Lars> system, regardless of whether you cro
| * Akim
| | Then let me restate my question: why don't you use AC_TRY_EVAL just
| | like in AC_EXEXT: this is a good first step I think.
|
| Umm.. I assume you mean to ask "why not use AC_TRY_EVAL in AC_EXEEXT
| just like in AC_OBJEXT" (and not "..like in AC_EXEEXT")?
|
| If so, my question fo
| Pavel Roskin wrote:
| > I think it would be nice if anybody with Solaris and *BSD could run the
| > testsuite as well.
| >
| The testsuite itself fails under SuSE Linux 7.0:
|
| ==
| ./debug-148.sh: Testing the autoupdating of AC_OUT
> "Daniele" == Daniele Arena <[EMAIL PROTECTED]> writes:
Daniele> - Which version of autoconf do you want to be tested? The
Daniele> version on ftp://alpha.gnu.org/gnu/autoconf/, autoconf-2.49a,
Daniele> dates of August 11. Or should I checkout the CVS tree
Daniele> somehow?
Thanks for the p
| tools.m4:164 ignored near `tools.m4:183'
|
| I'm not sure what to do with the ignored as I got some on my Linux box as well.
No problems.
| I also tried on a QNX box (our torture test box for building our products)
|
| The configure script bombs out while creating config.status with a mess
> "Michael" == Michael Long <[EMAIL PROTECTED]> writes:
Michael> Hi, I spent about 2 hours trying to get autoconf to make
Michael> until I realized it picked up "/bin/m4" (my system's) instead
Michael> of "/usr/local/bin/m4" (gnu's)
Michael> I'm not sure exactly the best way to handle this,
> "Daniele" == Daniele Arena <[EMAIL PROTECTED]> writes:
Daniele> When do you plan to publish the new tarball?
This week IMHO (In My Hopeful Opinion).
| Hi, autoconfers
Hi!
| I've gotten a report from a user with having locale-related problems
| running the configure script that I supply. In other words, it works
| fine when running with LC_ALL=C but not in some other locales. What's
| failing is:
|
| expr "x$ac_package" : ".*[^-a-zA-Z
> "Morten" == Morten Eriksen <[EMAIL PROTECTED]> writes:
Morten> Hi, a bug has been introduced by one of the commits from the
Morten> last day or so. Upon this configure.in file
Morten> AC_INIT(configure.in) AC_PROG_CC
Thanks, I'm sure I'm responsible for this. Most certainly my recent
c
I'm sorry for having introduced this bug :(
These macros badly need to be rewritten, but that's for another
Autoconf that 2.50.
Here is what I'm applying:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* acgeneral.m4 (AC_PATH_TOOL, AC_CHECK
| 2000-10-17 Morten Eriksen <[EMAIL PROTECTED]>
|
| * acgeneral.m4 (AC_CHECK_TOOL[S]?): As AC_CHECK_PROG[S]? first
| tests the value of the VARIABLE argument when looking for
| executables in the PATH, we need to set it to the correct
| value from AC_CHECK_TOOL[S
| Here's the changelog entry:
|
| 2000-10-17 Morten Eriksen <[EMAIL PROTECTED]>
|
| * acgeneral.m4 (AC_CHECK_TOOL[S]?): As AC_CHECK_PROG[S]? first
| tests the value of the VARIABLE argument when looking for
| executables in the PATH, we need to set it to the correct
|
> "Tom" == Tom Bates <[EMAIL PROTECTED]> writes:
Tom> Hey, I've modified config.sub and config.guess to recognize
Tom> "mips-compaq-nonstopux".
Tom> How should I provide these changes to you? Diffs?
Diffs are perfect, sent to [EMAIL PROTECTED]
ou `cp cp ln' once for all?
Anyway, after all Autoconf could do an effort. What about this:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* acspecific.m4 (AC_PROG_LN_S): If neither `ln -s' nor `ln' work,
fall back to `cp'.
Index: acspe
h is
exhibited only on machines on which `expr' fails, which is probably
your case.
Here is what I'm currently checking in:
2000-10-18 Akim Demaille <[EMAIL PROTECTED]>
* acgeneral.m4 (_AC_SHELL_DIRNAME): The `sed' fall back was not
quoted.
Index: ac
[Restricted to Autoconf, this is not something that matters to Libtool
and Automake]
Maybe I overlooked something, but don't you simply face the fact that
you used $( ) to dereference a shell variable? That should not work.
Since you want it to work with Make too, I'd suggest ${ }.
BTW, using
Hi,
Werner raised this issue. I don't feel competent to judge whether it
should be addressed by Autoconf or not. I'd really like to have
opinions on this issue. Maybe we need something like we have for
TIME_WITH_SYS_TIME?
> I'm not too sure about the answer to your questions. I can't f
AC_DEFUN([AC_REQUIRE_CXX],
[AC_REQUIRE([AC_LANG_COMPILER(C++)])
AC_WARNING([Hey Joe! (C++ version)
])
])
Sorry, I don't have much time, so the answer is short :)
[AC_REQUIRE([AC_LANG_COMPILER(C++)])
is not good, you can't do that. Use AC_LANG_COMPILER_REQUIRE instead.
> "Martin" == Martin Wilck <[EMAIL PROTECTED]> writes:
>> [AC_REQUIRE([AC_LANG_COMPILER(C++)])
>>
>> is not good, you can't do that. Use AC_LANG_COMPILER_REQUIRE
>> instead.
Martin> Ok, far better (I still get "CPP called before CC" messages,
Martin> though). But then this comment:
Marti
| Eureka, quotes! Could you please test this construct:
|
| if $ac_need_defaults; then
| : ${CONFIG_FILES="$config_files"}
| fi
No, this is not good. I removed the quotes on purpose.
2000-02-10 Akim Demaille <[EMAIL PROTECTED]>
* acgeneral.m4 (_AC_OUTPUT_CONFI
As far as I'm concerned, I'm lost. I'm no longer sure your problem is
really related to ${FOO=$bar}, or, more precisely, that it is *only*
related to this.
This debate already partly happened, see `config.status is broken
under Ultrix' on
http://sources.redhat.com/ml/autoconf/2000-01/t
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I installed QNX currently distributed from the QNX site (uname
Pavel> -r shows 6.00) and I couldn't reproduce the problem with
Pavel> ${FOO=$bar}
You're impressive! Your testing is incredibly conscientious, and
therefore precious.
> "David" == David Morgan <[EMAIL PROTECTED]> writes:
>>
>> test s${CONFIG_FILES+et} = set || CONFIG_FILES=$config_files
Yes, sorry I forgot to include the quotes. I really meant this:
test "${FOO+set}" = set
which is used all over Autoconf. There is no reason to change this.
| Hello!
| One thing was broken recently:
|
| /bin/sh -n autoconf
|
| doesn't work on FreeBSD and QNX if autoconf is not in the current
| directory.
No kidding!?! That's only with `-n' or any `sh autoconf' will fail?
| This patch should probably be reverted, at least partially:
I'm taking
> "Andrej" == Andrej Borsenkow <[EMAIL PROTECTED]> writes:
Andrej> bor@itsrm2% ./autoupdate --help autoupdate requires GNU sed
Andrej> Just curious, what are the reasons behind it? This is with
Andrej> current CVS.
It uses regexps that are not supported by other seds, which is just
one aspe
> "Andrej" == Andrej Borsenkow <[EMAIL PROTECTED]> writes:
Andrej> 1. Currently, it prevents me (and everybody without GNU sed)
Andrej> from making autoconf:
That's a bug in CVS. Run touch man/autoupdate.1.
Andrej> 2. I've installed GNU sed as gsed, but autoconf's confgiure
Andrej> does n
> "Andrej" == Andrej Borsenkow <[EMAIL PROTECTED]> writes:
Andrej> 1. Currently, it prevents me (and everybody without GNU sed)
Andrej> from making autoconf:
Admittedly `autoupdate --help/--version' should not fail when GNU Sed
is not installed. I'll fix that.
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Admittedly `autoupdate --help/--version' should not fail when
Akim> GNU Sed is not installed. I'll fix that.
Actually this would put hair in autoupdate, maybe we don't really need
that.
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> David, could you run it too?
Here is his answer.
--
From: David Morgan <[EMAIL PROTECTED]>
Subject: Re: Success (most
> "Daniele" == Daniele Arena <[EMAIL PROTECTED]> writes:
>> > ./config.status: 7: Syntax error: end of file unexpected
>> (expecting "}")
>>
>> I'll be very interested to see your config.status
Daniele> Then here it is... Enjoy!:)
When, the error message is not enough to understand what's
> "David" == David Morgan <[EMAIL PROTECTED]> writes:
David> Neutrino is very different from QNX 4 - it is more Unix
David> compliant - I think :)
It would be great to document the various system just like we started
with the different shells.
> "David" == David Morgan <[EMAIL PROTECTED]> writes:
David> The problem is the expr replacement and the sed on ac_dir.
David> The expr parts returns '.' on stdout (correct) and 1 - which
David> seems wrong.
So to summarize, the problem is that if you run this:
AC_INIT
echo AC_SHELL_DIRNAM
| + print Direct use
print ?!?!? There are only `echo's in this script. What a strange
way of tracing a script.
| Direct use
| {One}
| {line}
| {Two
| lines}
This is correct.
| Indirect Use with Quotes
| {One}
| {line}
| {Two
| lines}
This is correct.
| Indirect Use without Quotes
| {line
Same process, could you run this one please?
#! /bin/sh -x
ac_nl='
'
IFS=" $ac_nl"
debug=:
me=`echo "$0" | sed 's,.*/,,'`
SHELL=${CONFIG_SHELL-/bin/sh}
config_files="Makefile"
ac_given_srcdir=.
ac_given_INSTALL="/usr/bin/install -c"
# If no file are specified by the user, then we need to
how about this one?
#! /bin/sh -x
ac_nl='
'
IFS=" $ac_nl"
debug=:
me=`echo "$0" | sed 's,.*/,,'`
SHELL=${CONFIG_SHELL-/bin/sh}
config_files="Makefile"
ac_given_srcdir=.
ac_given_INSTALL="/usr/bin/install -c"
# If no file are specified by the user, then we need to provide default
# value.
> "Daniele" == Daniele Arena <[EMAIL PROTECTED]> writes:
Daniele> This one seemed to be working better... At least it gave no
Daniele> errors on exit and it did create a Makefile. Hope it's fixed?
OK, then the problem is that your shell is bad at following escaped
quotes. What I changed is
> "Alexander" == Alexander Thiel <[EMAIL PROTECTED]> writes:
Alexander> Is there a patched version of config.sub, or do you want me
Alexander> update it and send in the diffs.
See the module `config' on subversions.gnu.org, and send diffs to
[EMAIL PROTECTED]
Akim
> "Daniele" == Daniele Arena <[EMAIL PROTECTED]> writes:
Daniele> This is a nice question. Thanks for asking.:) I'll put aside
Daniele> my personal considerations, and advocate the cause of BSDI
Daniele> 3.1 .
Arg, sorry, I was lost again, thinking the failure was observed on QNX
something.
> "David" == David Morgan <[EMAIL PROTECTED]> writes:
David> Akim, What are you asking for here?
Some humanity in all this mess :)
What I mean is that I like to know what's behind the names. I'd like
the documentation to present the systems just like we started
presenting a few shells. So
| The script results are:
|
| .
| 1
Does it *always* fail, or it's just the operator | which does not
erase failures?
expr 'a' : '\(a\)'; echo $?
expr 'a' : '\(b\)' '|' 'a' : '\(a\)'; echo $?
>>>>> "David" == David Morgan <[EMAIL PROTECTED]> writes:
David> Akim Demaille wrote:
>> | The script results are: | | . | 1
>>
>> Does it *always* fail, or it's just the operator | which does not
>> erase failures?
>>
&g
> "David" == David Morgan <[EMAIL PROTECTED]> writes:
David> Hope this helps
Yes, it does, thanks!
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I thought about this construct, but I decided not to fix since
Pavel> the right fix is not to depend on GNU sed at all.
Don't do that Pavel, that's wasting your time (unless you refer to
using Perl now).
Pavel> I think "sed" is s
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello! The problem with FreeBSD ignoring "exit 77" can be
Pavel> reproduced on "the other OS :-)" using zsh.
Pavel> configure.in: AC_INIT exit 59 AC_OUTPUT(Makefile)
Pavel> $ export PS1 $ autoconf $ bash configure; echo $? 59 $
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> I assume you removed all the "p"s, and not just the last one.
Yep, I did. I think we are going to drop the `expr' branch. BSDI's
`expr' is so deeply broken that it hides it successes, which results
in twice the dirname.
Pfff. This
| On Oct 25, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| >>>>>> "Daniele" == Daniele Arena <[EMAIL PROTECTED]> writes:
| Daniele> This one seemed to be working better... At least it gave no
| Daniele> errors on exit and it did create a Makefile
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Oct 26, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Yep, I did. I think we are going to drop the `expr' branch.
Alexandre> Yep. We've had too much
In order to properly implement the proposal of Alexandre (expr=false
when we can't trust it), more responsibility should be moved into
Mash, in particular things like _AC_INIT_PREPARE_ENVIRONMENT. It is a
good thing, it is independent from Autoconf and useful to any Mash
project (understand `aut
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> Is it true (for a shell) that $0 is always a full pathname?
Thomas> (it could be a relative one, which complicates things a
Thomas> little).
I've never met any counterexample. A brand lot scripts out there use it.
It would really help if someone who has an access to an Ultrix could
run the following guy. That's the main reason why there is no 2.49b
release. If someone knows somebody who has an access, please
denunciate her :)
Better yet, if someone knows a means to have an ssh account on an
Ultrix machi
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> $0 is a full pathname if that's the way the script was invoked
Thomas> (I assume that's what you are saying - if it was not invoked
Thomas> with a full pathname, it really depends on the shell that was
Thomas> used to look up t
> "David" == David Morgan <[EMAIL PROTECTED]> writes:
David> Akim, Have a chat to the folks at www.rtr.com
David> They advertise a Dec Ultix as part of their porting center.
David> See http://www.rtr.com/newrtr/Porting01.htm
Wow! Nice url! But it's not free :( I'll try though if there i
You're right. I'm actually referring to a PATH resolution.
~ % PATH=/tmp:$PATH thomas.shnostromo 18:25
/tmp/thomas.sh
/tmp/thomas.sh param
...done
Thanks for the report. Actually none is really grave. The failure of
test 28 is known, we just have to decide how we want to fix it
---which is currently being discussed. The failure of test 66 just
demonstrates that AC_FUNC_MMAP forgets to clean its test file, which
will fix shortly.
Thanks!
Great! Thanks Alexandre!
| Direct use
| {One}
| {line}
| {Two
| lines}
OK.
| Indirect Use with Quotes
| {One line}
| {Two
| lines}
Not OK.
| Indirect Use without Quotes
| {One}
| {line}
| {Two
| lines}
OK.
This is the big problem I probably misunderstood (and diagnosed as
`quotes are inclu
> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
Bruce> Hi Alexandre (or someone on autoconf),
Bruce> Just wondering if this might ring any bells for anyone. If
Bruce> someone already knows of the causes and workarounds, advice is
Bruce> easier than trial-and-error research
I'm not
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>> I'm afraid that we will be overwhelmed with such "bugreports" :-(
Mo> Yup, it is very hard to figure out what is going wrong when
Mo> something like this happens. You may get swamped with "bug
Mo> reports" like mine. Better to hack some code
| On Oct 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| >
| > default="a b c"
| > : ${list1=$default}
| > : ${list2="$default"}
|
| > echo "$list1" | cat -v
| > echo "$list2" | cat
> "Paul" == Paul Martinolich <[EMAIL PROTECTED]> writes:
Paul> Is there a way to cleanly prevent these macros from setting
Paul> [C,F]FLAGS to "-g -O2" by default?
Nope. Nuke them afterwards.
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Thus we see that Akim intended to submit only a copyright
Pavel> change but somehow he submitted other changes.
How delicately said :) :) :)
think this is fixed now. It looks like another incarnation of
2000-11-03 Akim Demaille <[EMAIL PROTECTED]>
AC_REQUIRE and AC_DEFUN_ONCE don't work properly together. This
caused strange messages about AC_ARG_PROGRAM.
Reported by Jim Meyering.
* a
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> OK, I just wanted to know if there was a reason for the current
Lars> behaviour before I considered working on a patch for it. Since
Lars> noone else has objected, I just might create one :)
Personally I'm not too much in favor of thi
I was about to check another sanity check in, but unfortunately the
current Autoconf does not pass it :)
Since it's probably a lot of fun to track down the origin of the
following output, since I know some of the audience of autoconf@ likes
this kind of tracking, let's track it down altogether :
701 - 800 of 1987 matches
Mail list logo
