> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> byacc is portable, and has the advantage (in contrast to
Thomas> bison) of being written in ANSI C.
... which is written in?
> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> bison relies on alloca, which is not standard.
There are two meaning of `relies alloca':
- bison.exe uses alloca
but has the machinery to emulate it when missing.
No problem was ever reported.
- the parsers it outputs u
>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Would that be accepted? For some of my projects, I don't need
Akim> nor want the .gz, I just want
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hi, Tom! Failure (non-zero exit code) of a command inside a
Pavel> "for" loop doesn't make "for" fail.
>> Actually, it does (in my test with bash) if `set -e' is used.
>> Doesn't BSD make invoke sh that way?
Pavel> I forgot to say
(Why bug-autoconf???)
| Is the use of variables in implicit rules portable?
|
| .c.$(OBJEXT):
| ...
I don't know. Maybe Automake folks do?
| There are compilers which don't accept `.cc' but need `.cpp' for C++
| files. Among them are z/OS (by default) and various compilers for
| MS-DOS and Windows. What about support for a CXXEXT variable? It is
| quite easy to add a rule
|
| .cc.cpp:
| $(CP) $< $@
Well, this is a problem
Is there anything people would want to put into CVS Autoconf before
making a snapshot?
es and files (AC_SUBST,
AC_SUBST_FILES).
ChangeLog entries:
**
ChangeLog 3 Sep 2002 06:15:44 - 1.1991
******
2002-09-03 Akim Demaille <[EMAIL PROT
| Akim Demaille writes:
| > the following paragraph is not honored by gettextize:
| >
| > `aclocal.m4' at top level
| > -
| >
| >If you do not have an `aclocal.m4' file in your distribution, the
| > simplest is to concatenate the
| It is correct. If gettextize did not copy these files, the subsequent
| 'aclocal' invocation would fail. I consider this a bug in the
| 'aclocal' program version 1.5.
Ah, I now understand (I think). In the ``default'' environment,
gettext macro files are installed where aclocal will find them
> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
Andreas> The default value of ac_config_libobj_dir is wrong, it should
Andreas> be $srcdir. Similarily, AC_CONFIG_LIBOBJ_DIR should prepend
Andreas> $srcdir to the directory.
Arg, you are right. But I'm not sure sticking srcdir in
a
| An obvious, though not very elegant, solution would be to bootstrap like
| this instead:
|
| --
| #!/bin/sh
|
| noreadme=
| test -f README || noreadme=yes
| test x$noreadme = x || touch README
| set -x
| aclocal
| autoheader
| automake -i --add-missing --copy
| set +x
| test x$noreadme = x ||
| > From: Akim Demaille <[EMAIL PROTECTED]>
| > Date: 06 Sep 2002 13:50:20 +0200
| >
| > >>>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
| >
| > Andreas> The default value of ac_config_libobj_dir is wrong, it should
> "Ronald" == Ronald Landheer <[EMAIL PROTECTED]> writes:
>> Please, promote autoreconf use for bootstrapping. That way, we
>> will be reported more cases, more bugs etc. which is always a good
>> thing. In addition, in the future, if we add new people in the
>> build system (such as the re
| Index: ChangeLog
| from Akim Demaille <[EMAIL PROTECTED]>
|
| * lib/autoconf/functions.m4 (AC_FUNC_GETLOADAVG): Use $srcdir when
| looking for a replacement file.
| * lib/autoconf/general.m4 (AC_CHECK_DECLS): Check that the
| directory is relative.
|
If anybody sees a good reason to hold the release, please speak up
now!
| Using autoreconf leaves me without any way to work around this problem,
| unless I make a bootstrap script anyway (calling `touch README` before
| autoreconf to make the problem disappear).
Precisely. That's why I still don't understand your argument. I have
this:
| ~/src/a2ps-4.13 % cat
The Autoconf Team -- Akim, Alexandre, Jim, Paul, and Tom -- is
extremely happy to announce the release of Autoconf 2.54!
- Why should I upgrade from 2.53?
Several bug fixes, improved portability, no known incompatibility with
2.53, forthcoming Automake 1.7 requires 2.54.
Running `autoreconf
>>>>> "Thomas" == Thomas E Dickey <[EMAIL PROTECTED]> writes:
Thomas> On 13 Sep 2002, Akim Demaille wrote:
>> - Why should I upgrade from 2.53?
>>
>> Several bug fixes, improved portability, no known incompatibility
>> with 2.53, forth
>>>>> "W" == W L Estes <[EMAIL PROTECTED]> writes:
W> On Wednesday, 18 September 2002,18:07 +0200, Akim Demaille wrote:
>> Automake 1.7 includes the PDF generation.
W> Can I ask how automake 1.7 will generate the pdf?
texi2dvi --pdf
W> and when
| Am Mon, 2002-09-23 um 10.49 schrieb Alexandre Duret-Lutz:
| > >>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html
| >
| > Ralf> .. which seems to indicate that libtool is the culprit.
|
> "Roger" == Roger Leigh <[EMAIL PROTECTED]> writes:
Ralf> .. still nobody wanting to care to fix it?
>> AFAICT it's fixed in CVS Libtool.
Roger> And in Debian.
Am I crazy suggesting that Debian Libtool be the next Libtool release?
| Alexandre Duret-Lutz wrote:
| > Bruce> My preference would be this:
| >
| > Could you send this to the list?
|
| Alright:
|
| I would really like to see the auto* tools packages (autoconf,
| automake and libtool) each adopt several of their worst
| clients' packages for regression testing.
| > I have not read all the details yet, but does anybody know what we
| > must do to cope with Libtool 1.4.2?
|
| How about this patch to Autoconf? It should let us limp along until a
| new libtool version is published.
|
| --- old/BUGS 2002-03-26 08:14:37.0 -0800
| +++ new/BUGS 200
| hi all,
| i'm trying to learn autoconf by converting one of my programs to use
| autoconf. i'm having difficulty; here's what i tried:
|
|% cp Makefile Makefile.orig
|% mv Makefile Makefile.in
|% autoscan
|% mv configure.scan configure.in
|% autoheader
|% autoconf
|
2.13 tools.
Arg... I'm applying the following patch. It should help avoiding
such pitfalls, plus anyway it is better this way.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* bin/autoscan.in (output): Output AC_PREREQ.
(%needed_macros): Add AC_PREREQ so t
| The graph of interproject dependencies, including version-specific
| dependencies, is very complex -- bordering on intractable.
|
| Do the developers of autoconf believe this is true?
I don't. I'm not interested in this thread either.
ions, please run the test suite of
Autoconf 2.55 on it, and report the results to
[EMAIL PROTECTED]
ChangeLog entries:
2002-10-25 Akim Demaille <[EMAIL PROTECTED]>
Version 2.54a.
* Makefile.maint: Update from the Coreutils.
(AMTAR): Remove, obsolete.
(autom
results to
[EMAIL PROTECTED]
ChangeLog entries:
**
ChangeLog 28 Oct 2002 08:57:40 - 1.2075
**
2002-10-28 Akim Demaille <[EMAIL PROTECTED]>
Version 2.54b.
* tests/foreign.at (Libtool):
901 - 929 of 929 matches
Mail list logo
