Hi all,
> Le 8 déc. 2018 à 00:48, Bruno Haible a écrit :
>
> How does that sound? As far as I can see, this would solve the problems
> (A), (B), (C) in the Bison support, while at the same time not regressing
> behind 2.69 regarding the Yacc support.
It sounds excellent to me.
While at it, I
Hi!
I fell on this while writing a macro wrapping AC_CONFIG_COMMANDS.
This is 2.69. I have not seen indications in the documentation
that the first argument must be 'a literal'.
$ cat configure.ac
AC_INIT
AC_CONFIG_COMMANDS([m4_default([], [foo])], [echo foo])
AC_OUTPUT
$ autoconf
$ ./configure
Hi all,
Bison has tests with semicolons in their title. Everything is
displayed properly, except ./testsuite -l. Indeed, I can read
in testsuite:
232;types.at:108;yacc.c api.value.type={union foo};api.value.type;
233;types.at:108;yacc.c %union { float fval; int ival; };;api.value.type;
Ping!
Le 4 mars 2013 à 18:48, Akim Demaille a...@lrde.epita.fr a écrit :
Hi Autofolks,
The fact that Autoconf sets YACC to bison --yacc is troublesome,
as it emasculates the Bison down to a Yacc-calf (I wouldn't like
to be the vet performing the bollocksectomy of a Bison).
The appended
Le 19 mars 2013 à 19:20, Paul Eggert egg...@cs.ucla.edu a écrit :
Thanks, I installed that into Autoconf with a slightly terser NEWS entry:
- AC_PROG_YACC now uses 'bison -o y.tab.c' instead of 'bison -y', so that
by default it no longer warns about Bison extensions. Add -Wyacc to
Le 25 févr. 2013 à 14:26, Akim Demaille a...@lrde.epita.fr a écrit :
Actually I just found what could arguable called a bug in
Bison:
$ ls f.y
f.y
$ bison -o y.tab.c -d -v f.y
$ ls y.*
y.output y.tab.c y.tab.h
where I would have expected y.tab.output. Fortunately
When CXX is specified, configure does not report that
it is looking for a C++ compiler, nor its answer.
$ cat configure.ac
AC_INIT
AC_PROG_CC
AC_PROG_CXX
$ autoconf
$ diff -U 100 =(./configure) =(./configure CC=gcc CXX=g++)
--- /tmp/zshIZDChp 2012-10-26 13:39:32.0 +0200
+++
Hi all,
Bison's test suite includes:
AT_ARG_OPTION([compile-c-with-cxx],
[compile C parsers with the C++ compiler])
and running --help shows:
$ ./tests/testsuite --help | tail
default for debugging scripts
-d, --debuginhibit clean up and top-level
Le 23 juil. 2012 à 15:22, Eric Blake a écrit :
* doc/autoconf.texi (@dvarv): New.
Use it where optional macro arguments default to other arguments.
---
doc/autoconf.texi | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
ACK with one tweak. Do you still have push
-8-
Hi all,
I was reading at the documentation of m4_map_args_pair, which reads as
follows:
-- Macro: m4_map_args_pair (MACRO, [MACRO-END = `macro'], ARG...)
For every pair of arguments ARG, invoke MACRO with two arguments.
If there is an odd number of arguments, invoke MACRO-END,
(wow, _that_ is quite a list of CCs. Hi mum!)
Hi Eric,
Le 26 juin 2012 à 18:18, Eric Blake a écrit :
Eek - that just shows that I'm really behind on reading my email.
Thou shalt be punished. Beware of my wrath.
Just from reading this summary, the idea of improving AC_PROG_LEX and
Le 13 avr. 2012 à 10:16, Stefano Lattarini a écrit :
I think the best fix in the long term would be to enhance AC_PROG_LEX to set
a variable telling whether $LEX is flex or not (similarly to what is done by
AC_PROG_CC etc.). The Bison's configure could simply use this variable to
determine
hi Stefano!
Le 13 avr. 2012 à 10:16, Stefano Lattarini a écrit :
I confess I am a bit frustrated to define FLEX to yes/''
I agree with you, and in fact I find that confusing. I understand that it
is done in order to be more consistent with what AC_PROG_CC and friends do,
but here clarity
[This started in bison-patches].
Le 27 mars 2012 à 16:27, Stefano Lattarini a écrit :
On 03/27/2012 04:16 PM, Akim Demaille wrote:
[BIG SNIP]
diff --git a/configure.ac b/configure.ac
index 622da5d..5c97683 100644
--- a/configure.ac
+++ b/configure.ac
@@ -110,6 +110,9 @@ AC_SUBST
Hi Ben,
Le 5 oct. 2011 à 18:40, Ben Pfaff a écrit :
Akim Demaille demai...@gostai.com writes:
The JVM is quite happy with that. Unless you make the name
invalid by setting LC_ALL to C for instance, which Autoconf
does.
Glib supports a G_FILENAME_ENCODING environment variable
Hi Paul!
Le 4 oct. 2011 à 08:42, Paul Eggert a écrit :
On 10/03/11 07:39, Akim Demaille wrote:
The JVM is quite happy with that. Unless you make the name invalid
by setting LC_ALL to C for instance, which Autoconf does.
Eeuuuw! (I think that's the proper technical term. :-)
In French
Hi!
I just spent an unfair amount of time on a problem due to configure setting
LC_ALL to C. The failure was the JVM being unable to load a class file right
in front of it (in .) under configure, but by hand it worked fine.
It turns out that the person who had the problem used French
EB == Eric Blake [EMAIL PROTECTED] writes:
Something like a new primitive eval and return quoted would fill
the gap.
Yes, m4 has a TODO item about adding the qindir builtin (and which
I will probably do for m4 1.6).
Why forcing the requirement that the argument is a macro name instead
Le 22 avr. 08 à 14:45, Eric Blake a écrit :
Really, the problem is
that there is no way to determine whether $1 is safe to expand,
short of
expanding $1; thus, if it was not safe, you've already screwed up the
state of the m4 parsing.
I always felt m4 lacks an eval macro. Not the one for
Akim:
I see this when configuring bison:
checking whether g++ builds executables that work... yes
checking for Java virtual machine... rm: conftest.dSYM: is a directory
java
rm: conftest.dSYM: is a directory
checking for Java compiler... javac -source 1.3
checking for Java virtual machine...
Le 12 nov. 07 à 12:15, Hans Aberg a écrit :
On 12 Nov 2007, at 11:36, Akim Demaille wrote:
I did have a problem when installing XCode 3.0,
I experienced the problem (in connection with Fink) when updating
the Xcode that came with the Mac OS X 10.4.0 installation DVD (don't
know about
Le 6 nov. 07 à 15:33, Benoit Sigoure a écrit :
On Nov 6, 2007, at 3:25 PM, Ralf Wildenhues wrote:
* Benoit Sigoure wrote on Tue, Nov 06, 2007 at 03:13:07PM CET:
Anyone aware of any portability issue with shell parameter
expansions?
Solaris 10 /bin/sh knows neither
${foo#bar}
${foo%bar}
] /tmp $ cat
configure.ac23:24:18
AC_INIT
AC_PROG_CC
AC_PROG_F77
[EMAIL PROTECTED] /tmp $ autoconf --
version 23:26:11
autoconf (GNU Autoconf) 2.60
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2006 Free Software
Le 25 déc. 06 à 11:46, Thomas Schwinge a écrit :
[I added the patch's author, Akim Demaille, to the cc list, as it
was not
sure if he's still reading the list.]
You're right, I'm not.
Hello!
Hi, and merry Chrismas.
On Sun, Dec 24, 2006 at 04:21:50PM -0800, Paul Eggert wrote:
Benoit
Le 28 oct. 06 à 16:56, Akim Demaille a écrit :
Le 28 oct. 06 à 01:03, Ralf Wildenhues a écrit :
@example
#! /bin/sh
set -e
-foo=''
-test -n $foo exit 1
+false exit 1
echo one
if :; then
- test -n $foo exit 1
+ false exit 1
fi
echo two
@end example
I would simplify even
Years ago, it was suggested to simplify the handling of cross-compilation,
and in particular to no longer require --build: --host alone is the sign that
we're cross compiling.
In Autoconf 2.60, there still remains FIXME about this in general.m4.
How about getting rid of all this now?
Also, the
Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes:
Hi Akim,
* Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:
Akim == Akim Demaille [EMAIL PROTECTED] writes:
Some time ago I sent this message for which I had no answer.
I suggest that the AC_DEFINE family explicitly
Stepan == Stepan Kasal [EMAIL PROTECTED] writes:
Hello,
* Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:
I suggest that Automake provide the same feature for AM_CONDITIONAL:
well, you already implemented it, granting Alexandre one point for
his hint:
http
Akim == Akim Demaille [EMAIL PROTECTED] writes:
OK. I've suggested splitting the autotest test suite before.
Let's look at that idea again sometime later (one file per test, and
source them for execution from the main test suite script), it's bound
to give both execution time
OK. I've suggested splitting the autotest test suite before.
Let's look at that idea again sometime later (one file per test, and
source them for execution from the main test suite script), it's bound
to give both execution time improvements and portability improvements.
Using functions should
Akim == Akim Demaille [EMAIL PROTECTED] writes:
Hi!
Some time ago I sent this message for which I had no answer.
I have this package at hand, say FooBar, which installs a prefixed
form of config.h. Its own macros are, of course, named FB_*, which is
m4_pattern_forbidden. But then I
Le 31 mai 06 à 18:38, Stepan Kasal a écrit :
Hello,
* Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:
I suggest that Automake provide the same feature for AM_CONDITIONAL:
well, you already implemented it, granting Alexandre one point for
his hint:
http://lists.gnu.org
FWIW, I was recently browsing some configure file, and saw that IFS
was used, and then defined afterward. I can't seem to resurrect my
old CVS checkout, so I can't tell if the trouble persists currently,
but that should be easy to check. Cheers!
~/src/texinfo % grep -w IFS configure | sed 6q
I have this package at hand, say FooBar, which installs a prefixed
form of config.h. Its own macros are, of course, named FB_*, which is
m4_pattern_forbidden. But then I have to explicitly m4_pattern_allow
all my FB_PACKAGE_VERSION etc.
I suggest that the AC_DEFINE family explicitly allow its
Paul == Paul Eggert [EMAIL PROTECTED] writes:
local isn't in POSIX so I'd avoid it in portable scripts.
Doh. Thanks.
For what it's worth, I briefly searched for this issue and found these
bug reports dated this year where someone used local in a shell
script and someone else
Andreas == Andreas Schwab [EMAIL PROTECTED] writes:
Akim Demaille [EMAIL PROTECTED] writes:
if (local foo) /dev/null 21; then :; else
local () { true; }
fi
Note that local is only valid in function context, so this will always
produce a failure.
Thanks, I didn't know. How about
Now that there are no doubts about the portability of shell functions
(in the sense that there's always a shell on the machine that supports
function ---and maybe the documentation should reflect this), I'm
curious about the support of return and local. Is there anything
known about them? ISTR
Paul == Paul Eggert [EMAIL PROTECTED] writes:
+ac_save_IFS=$IFS; IFS='-'
+set x $ac_cv_$1
+shift
+IFS=$ac_save_IFS
+$1_cpu=$[1]
+$1_vendor=$[2]
+$1_os=$[3]
+
+case $[#] in
+0|1|2) ;;
+*)
+ shift; shift; shift
+ for ac_arg
+ do $1_os=$1_os-$ac_arg
+ done;;
Le 24 mars 05, à 21:46, Alexandre Duret-Lutz a écrit :
config-aux/ dir is coherent with how this directory was used 10 years
ago.
djm indeed called this the directory for configuration auxiliary
files
So maybe it is also time to introduce a more recent name for the
macro too.
Stepan == Stepan Kasal [EMAIL PROTECTED] writes:
The option 3) is much safer, and we should rather spend our effort there.
One question remains, what is autoconf with functions.
Autoconf-3 will be probably able to assume shell functions.
But I don't think we have to wait or split the
Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes:
Might be nice to have the information reusable as well
(--config comes to mind). See below.
The idea is nice, but the way to use --config should be documented: in
particular how to split properly the output when some arguments
include
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
Paul == Paul Eggert [EMAIL PROTECTED] writes:
[...]
Paul * doc/autoconf.texi (@copying): Allow programs in this
Paul manual to be copied under the GPL.
[...]
Sounds sensible to me. The last sentence of fdl.texi is
If your
Paul == Paul Eggert [EMAIL PROTECTED] writes:
Bruce Korb [EMAIL PROTECTED] writes:
What if you simply stated:
Any programming examples incorporated into this document are
hereby released to the public domain and are free for anybody to
use any way they like.
That's too broad, as
Paul == Paul Eggert [EMAIL PROTECTED] writes:
This is long enough to be copyrightable. Currently this text is
redistributable only under the terms of the GNU FDL, which doesn't
allow you to cut-n-paste it into your program. I'm trying to say
that it's OK to cut-n-paste this into GPLed
Noah == Noah Misch [EMAIL PROTECTED] writes:
I hope I have missed a general solution. Ideas?
Fix m4. It has fundamental flaws from its inception:
- text processing builtins (regexp etc.) should return quoted strings,
they do not.
- eval should do what it does it almost all the other
Le 2 déc. 04, à 21:45, Paul Eggert a écrit :
That's why I'm glad to see this macro (and related changes) moving
ahead, so I can feel free to start using C99 features without worry
(other than users may be forced to upgrade their systems to support
C99 if they have old compilers, but at least
Patrice == Patrice Dumas [EMAIL PROTECTED] writes:
the native size of integers (although AC_CHECK_SIZEOF
may be the solution, it seems C oriented).
It should not: the architecture is made for these tests to be
implementable independently of the language.
Dive into fortran.m4 and complete
Gary == Gary V Vaughan [EMAIL PROTECTED] writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Would you mind if I ship an implementation of m4sugar.m4 with the
next release of GNU m4, with an eye to replacing parts of it with
C at some point?
There are some issues in m4sugar
Nicholas == Nicholas R Markham [EMAIL PROTECTED] writes:
I recently decided to try to apply the suggestion mentioned in section 17.5 of
the autoconf manual - namely, to hardcode only the relative path from prefix to
datadir (or maybe from bindir to datadir) and try to determine prefix at
Peter == Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 26. August 2004 17:17 schrieb H. J. Lu:
[EMAIL PROTECTED] libunwind-0.98]$ ./config.status --recheck --enable-debug
config.status: error: unrecognized option: --enable-debug
Try `./config.status --help' for more
On Wed, 2003-12-17 at 10:05, Akim Demaille wrote:
But beware, autoreconf can be dangerous and doesn't always work.
Why?
To make a long story short, some examples:
1. autoreconf doesn't work if a package has not been prepared for the
particular version of auto*tools autoreconf
But beware, autoreconf can be dangerous and doesn't always work.
Why?
Hi,
On Wed, 10 Dec 2003 17:55:04 +0100, Eric Sunshine wrote:
...
At the very least, it would be a good idea to
only use ls -ld after checking that such usage is valid (i.e. ensure
that ls -ld actually works, and works as intended on the target platform).
As the possible 'keep
On Wed, Nov 26, 2003 at 06:14:01PM +0100, Akim Demaille wrote:
Does somebody have an autoconf macro to handle adding -R/path/
stuff when libraries are found?
You find it in the autoconf-lib-link directory of the GNU gettext
distribution.
How about moving these macros
Does somebody have an autoconf macro to handle adding -R/path/ stuff when
libraries are found?
You find it in the autoconf-lib-link directory of the GNU gettext
distribution.
How about moving these macros into Autoconf now?
(Answering only for Automake, because I've also been confused by
Akim's last statements about announcements that shouldn't be
considered official.)
Sorry about this. I was trying to make a difference bw pre-released
on my web site, and really released on GNU site. Maybe that was wrong
:(
ps. I've already sent this to [EMAIL PROTECTED]
Thanks. It's discussed there.
Akim Demaille wrote:
Yes, but again, some dummies ---such as me---, will really believe FC
is polymorphic wrt the Fortran flavor.
Akim, it's not that you're dumb, but your use of the macros in the
test program is *extremely atypical*. You weren't actually *using*
the macros
Akim Demaille wrote:
Nope, indeed, that's why it's too late to change the others. But, IMHO,
this interface is merely the unfortunate result of history, where
Autoconf was not designed from scratch to support several languages.
That's also why I would much better enforce
On Sat, 15 Nov 2003, Akim Demaille wrote:
Nope, indeed, that's why it's too late to change the others. But,
IMHO, this interface is merely the unfortunate result of history,
where Autoconf was not designed from scratch to support several
languages. That's also why I would much better
Steven G. Johnson a dit:
On Fri, 14 Nov 2003, Akim Demaille wrote:
Steven, you don't seem to read my messages in another thread,
precisely related to this:
http://mail.gnu.org/archive/html/autoconf-patches/2003-10/msg00116.html
Akim, the only justification you give there is that you had
Akim Demaille [EMAIL PROTECTED] writes:
2.58 was not announced because it has a problem that affects Automake.
I never announced it, and I am somewhat unhappy that Debian has
already shipped it. All this mess results from the now asynchronous
process to upload files on ftp.gnu.org
In a discussion about the AC_FC_FREEFORM macro (which figures out how
to enable freeform-source support for Fortran, if possible), Akim
wrote:
[...]
Steven, you don't seem to read my messages in another thread,
precisely related to this:
Hello!
I've seen an announcement in [EMAIL PROTECTED] that Automake
1.7.9 has been released with Autoconf 2.59. I thought it was a typo
because Autoconf 2.59 has never been announced in the same list.
Indeed, I checked NEW in CVS Autoconf, it mentions the 2.59 release on the
same
What I see is that half of traffic is spam and that neither Autoconf 2.58
nor Autoconf 2.59 have been announced there. However, the Autoconf 2.58
announcement is in the autoconf-maintainers archives.
2.58 was not announced because it has a problem that affects Automake.
I never announced
Akim Demaille [EMAIL PROTECTED] writes:
What I see is that half of traffic is spam and that neither Autoconf 2.58
nor Autoconf 2.59 have been announced there. However, the Autoconf 2.58
announcement is in the autoconf-maintainers archives.
2.58 was not announced because it has
On 2003-11-12T16:12+0100, Akim Demaille wrote:
) The Autoconf team is happy to announce its release 2.59. For the time
) being it is only available from my web site, but hopefully it should
) be on maintstream servers soon. I'll send the release notification
) once Autoconf available
In the Fine Manual:
@node Coding Style
@section Coding Style
In order to highlight the recommended coding style, here is a macro
written the old way:
@example
dnl Check for EMX on OS/2.
dnl _AC_EMXOS2
AC_DEFUN(_AC_EMXOS2,
...
and the new way:
@example
# _AC_EMXOS2
#
I encountered the following problems on autoconf 2.57g on HP-UX 11.00:
1. On make install, config/install-sh did not have execute
permission. I added it then install went ok.
Thanks, I installed the following.
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* Makefile.cfg
2. When running autoheader, I got:
Use of uninitialized value in split at /usr/local/bin/autom4te at line
1008.
Use of uninitialized value in concatentation (.) or string at
/usr/local/bin/autom4te at line 1007.
unknown channel For example, try the following from the top-level
:
**
ChangeLog
**
2003-10-23 Akim Demaille [EMAIL PROTECTED]
Version 2.57g.
* config/config.guess, config/config.sub: Upgrade from masters.
2003-10-23 Akim Demaille [EMAIL PROTECTED]
* lib
which adds a
check for a sufficiently recent version of Emacs.
Thanks, I installed the following.
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* configure.ac: Quotation and formatting changes.
(EMACS): Don't set it if it is not recent enough to support
Hi,
I have a few files with custom Autoconf macros. I can merge these
files into the file acinclude.m4, but I would like to keep them
separate. Therefore I want the aclocal tool to know where to search
for the files. I do not want to to use aclocal -I ./config, because
now I only
That should read [emacs xemacs], rather than [macs xemacs]. :-)
Blush... Well, it's still better than an accidental [vi xemacs] :)
Thanks :)
OK, I installed this patch. I can't test it easily, though.
(For one thing, CVS autoconf doesn't build itself on my host,
since it depends on an alpha version of autoconf)
Does it? Where?
2003-09-30 Paul Eggert [EMAIL PROTECTED]
* lib/Autom4te/XFile.pm: Use Errno.
Released 2003-10-01, by Akim Demaille.
* Major changes in Autoconf 2.57e
Released 2003-09-29, by Akim Demaille.
** AC_CONFIG_COMMANDS
The directory for its first argument is automatically created. For
instance, with
AC_CONFIG_COMMANDS([src/modules.hh], [...])
$top_builddir/src
Paul == Paul Eggert [EMAIL PROTECTED] writes:
Paul Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
When people change configure.ac and run `make -j', that can
trigger simultaneous runs of autoconf, automake, and autoheader.
Paul If that's the main problem, then we can use a heuristic:
Eric Sunshine a dit:
Hello,
On Sat, 27 Sep 2003 19:06:55 +0200 (CEST), Akim Demaille wrote:
I just grabbed the tarball, and it works fine here
I tried with a more recent CVS m4, and with Debian's with success in
both
cases. Both M4 did produce exactly the same output.
How very strange
How very strange. Your successes prompted me to expand my testing to
additional platforms. In addition to my earlier trials, I used the
SourceForge CompileFarm machines, a MacOS/X machine to which I have
shell
access, and asked one of the other Crystal Space developers to test with
his
Eric Sunshine a dit:
On Sun, 28 Sep 2003 11:58:54 +0200 (CEST), Akim Demaille wrote:
Could you make the test case smaller? Are you sure all the tests were
run with the modified m4?
Okay, I narrowed down the excess arguments to m4_pushdef to the
following
tiny case:
AC_INIT([crystal], [1
Eric Sunshine a dit:
On Sun, 28 Sep 2003 11:58:54 +0200 (CEST), Akim Demaille wrote:
Could you make the test case smaller? Are you sure all the tests were
run with the modified m4?
I was able to narrow down the failed with exit status: 139 error to the
following tiny case:
AC_INIT
Eric Sunshine a dit:
Hello,
Hi!
So finally, some _real_ fun to find in Autoconf... Thanks...
;)
I have not looked at your traces yet, but may I ask you to try
the following m4 1.4? It is _not_ the regular 1.4, it is 1.4 + Debian
patches. If it works for you, we will quickly wrap it as
Eric Sunshine a dit:
On Sat, 27 Sep 2003 10:40:22 +0200 (CEST), Akim Demaille wrote:
So finally, some _real_ fun to find in Autoconf... Thanks...
I have not looked at your traces yet, but may I ask you to try
the following m4 1.4? It is _not_ the regular 1.4, it is 1.4 + Debian
patches
Hello,
I have been trying to compile the mpich 1.2.5 sources.
In the sources for ch_p4 device ie, in mpich/mpid/ch_p4/p4 when I try
doing a autoconf to recreate the configuration file I get the following
error :
configure.in:280: error: m4_defn: undefined macro:
hi,
I am novice in using autoconf tools..
Could you tell me why I am getting these errors..
autoheader-2.53
configure.in:8: warning: do not use m4_patsubst: use
patsubst or m4_bpatsubst
configure.in:17: warning: AC_PROG_LEX invoked multiple
times
configure.in:67: warning: do
It appears to be a wild use of Autoconf. It is certainly part of a
bigger system, and looking only at this file is of no use. Ask the
author how this is supposed to work.
This is my proposal. Does it work properly for you?
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* lib/autoconf/status.m4 (_AC_OUTPUT_COMMANDS): Make sure the
directory for AC_CONFIG_COMMANDS' first argument exists.
This makes valid the invocation
Hello,
I sent this bug report almost a year ago but never received a
response, nor has the problem been addressed, so I thought I would
try again.
Thanks for insisting :)
In Autoconf 2.57 (all releases) and in the CVS version, there is a
problem with AC_CONFIG_COMMANDS when it is
On Fri, 26 Sep 2003 15:26:47 +0200, Akim Demaille wrote:
This is my proposal. Does it work properly for you?
8-)=) I forgot to save the file before asking cvs diff...
ac_dir=`AS_DIRNAME([$ac_dest])`
+ AS_MKDIR_P([$ac_dir])
_AC_SRCPATHS([$ac_dir])
Yes, it works perfectly. Thank
[bug-autoconf@ has a stupid filter that doesn't let me through, so I'm
posting here instead.]
It should be fixed by now. Could you find out why you were blocked?
On some systems (eg. Linux) flock(2) does not work over network, but Perl
prefers that over fcntl(2) if it exists. So
Joseph D. Wagner [EMAIL PROTECTED] writes:
If it's still in alpha, could you please update the alpha package?
Even doing that takes some work, I'm afraid.
I'm willing to release 2.58 asap though.
* Major changes in Autoconf 2.57d
* Major changes in Autoconf 2.57b
Released 2003-08-24, by Akim Demaille.
** Autotest and local.at
The optional file local.at is always included in Autotest test suites.
** Warnings
The warnings are always issued, including with cached runs.
This became
The autoconf part of this feature is trivial (I can provide a patch if
that's useful), but I suspect I'd need to be able to write perl to
implement the aclocal end :-)
Fortunately, if we consider relative directories as local, we don't
need to look at AC_CONFIG_M4_DIR. Adding this
On Wed, Sep 24, 2003 at 02:19:06PM +0200, Akim Demaille wrote:
At the origin I was considering that AC_CONFIG_M4_DIR was
automatically passed to m4 as a -I, so instead of
m4_include([config/init.m4]) etc. you'd have m4_include([init.m4]).
Isn't there a chicken'n'egg problem? How can
%% Dr. David Kirkby [EMAIL PROTECTED] writes:
dk make[1]: Entering directory `/export/home/davek/atlc/src'
dk cd .. \
dk --gnu src/Makefile
dk /bin/bash: --gnu: command not found
This mean AUTOMAKE is empty.
On Mon, 2003-08-25 at 08:47, Akim Demaille wrote:
Hi,
Is there any means to run a script at the very end of running
configure?
AC_CONFIG_COMMANDS_POST(script) seems to run script at the end of
config.status, before recursing into CONFIG_SUBDIRS.
Directly invoking
Hi,
Is there any means to run a script at the very end of running
configure?
AC_CONFIG_COMMANDS_POST(script) seems to run script at the end of
config.status, before recursing into CONFIG_SUBDIRS.
Directly invoking a script from inside of the configure-script invokes
it before
I finally was able to get rid of the last package that needed Autoconf 1
only a year or so ago.
Gee!
Peter Akim Demaille writes:
In the long term, I think that a complete rewrite of this macro would
be most useful (i.e., actually checking the features we want, instead
of this hardwired list of names).
Peter Why bother? Since everyone is required to ship install-sh
Peter anyway, why
Akim == Akim Demaille [EMAIL PROTECTED] writes:
adl [...]
Akim We could do another release in the near future, let it be just to
Akim redirect the headers issues onto the package maintainers instead of
Akim the Autoconf lists.
adl BTW, an intersting fact about these header warnings
1 - 100 of 1456 matches
Mail list logo
