Tho the instance is particular to gnulib, it is of a more general
interest, too.
On 12/9/20 6:21 AM, Zack Weinberg wrote:
This conversation should happen on the Gnulib mailing list; both
git-version-gen and maint.mk are maintained there. I have no
particular opinion about whether it is
allowed it to complete successfully.)
On Sat, Sep 1, 2018 at 7:24 AM Bruce Korb wrote:
>
> I am unable to locate any package that provides pix.m4.
> No idea what it might be.
>
> autoreconf --symlink --verbose --install
> autoreconf: Entering directory `.'
> autoreconf: configure.
I am unable to locate any package that provides pix.m4.
No idea what it might be.
autoreconf --symlink --verbose --install
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
aclocal: error: aclocal: file
On Wed, Jul 11, 2018 at 11:11 AM Bruce Korb wrote:
>
> Hi,
>
> "NEED_LIBOPTS" *does* appear in an AM_CONDITIONAL:
>
> > AM_CONDITIONAL([NEED_LIBOPTS], [test -n "${NEED_LIBOPTS_DIR}"])
After reconf-ing with -, I have found:
autore
Hi,
"NEED_LIBOPTS" *does* appear in an AM_CONDITIONAL:
> AM_CONDITIONAL([NEED_LIBOPTS], [test -n "${NEED_LIBOPTS_DIR}"])
so I cannot figure out the source of the complaint.
> autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running:
Thanks. I fixed that bug. Meanwhile, it seems to me the autotools
ought to be searching installation places for libtool stuff rather
than choking with semi-indecipherable messages.
On Wed, Aug 16, 2017 at 1:39 PM, Eric Blake <ebl...@redhat.com> wrote:
> On 08/16/2017 03:25 PM, Bruce K
It won't hurt. It could (and likely would) slow down the bootstrap by
several milli-seconds. On the other hand, you won't have bootstrap
failures caused by unexpanded LT_LIBTOOL cruft. Fair trade in my book.
This fixes the "I don't know anything about libtool" error message.
Autoconf needs to be fixed, but meanwhile:
bootstrap: 1.49 1.50 bkorb 17/08/16 10:38:39 (modified, needs delta)
@@ -155,6 +155,12 @@ cp depsver.mf sntp/
cp bincheck.mf sntp/
cp depsver.mf sntp/
+export
think it was as
clear as the discussion about subscripts in C code.
Thank you both!
Cheers - Bruce
On Sun, Nov 23, 2014 at 2:22 PM, Gary V. Vaughan g...@gnu.org wrote:
Hi Bruce,
On 23 Nov 2014, at 21:38, Bruce Korb bruce.k...@gmail.com wrote:
AC_DEFUN([INVOKE_AG_MACROS_LAST],[
[if test X
AC_DEFUN([INVOKE_AG_MACROS_LAST],[
[if test X${INVOKE_AG_MACROS_LAST_done} != Xyes ; then]
GUILE_FLAGS
[ag_gv=$( exec 2/dev/tty ; set -x
gdir=$(pkg-config --cflags-only-I guile-${GUILE_EFFECTIVE_VERSION})
gdir=$(echo ${gdir#-I})
gdir=$(awk '/SCM_MICRO_VERSION/{ print @S|@3 }'
Autoconf
This manual (24 April 2012) is for GNU Autoconf (version 2.69), a
package for creating scripts to configure source code packages using
templates and an M4 macro package.
Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc.
[...]
15.2 Working With External
On 06/16/13 12:44, Zack Weinberg wrote:
Typo? AC_ARG_WITH, not AC_ART_WITH.
This might also explain the AS_HELP_STRING error.
Must have been. I fixed them both at once (replacing that with
AC_HELP_STRING, which seemed more correct). Now I see that
AS is preferred. I think it weird, but
On 05/09/13 09:24, Mona Pinjani wrote:
Hi,
I downloaded complexity-1.0 from http://ftp.gnu.org/gnu/complexity/
I am trying to run configure and I get this error
-bash-4.1$ pwd
/home/monap/complexity-1.0
-bash-4.1$ ./configure
## -- ##
## Configuring complexity 1.0 ##
##
On Thu, May 09, 2013 at 07:44:59PM +, Mona Pinjani wrote:
Hi Bruce,
Thanks for the quick reply. There is no install-sh in $HOME. Here is the
output you requested
-bash-4.1$ build-aux/config.guess
x86_64-unknown-linux-gnu
-bash-4.1$ grep 'Generated by GNU Autoconf' configure
#
Hi,
GCC's -g option takes an optional argument.
If you add to the command line:
./configure --enable-debug --disable-fast-install CFLAGS=-ggdb3
at some point, the script will remove the -g and then add it back in with a
space
+ eval 'ac_val=$ac_configure_args'
++ ac_val='
What might induce configure to insert a space after -g and before gdb3?
configure:15849: result: no
configure:15864: checking whether uname(2) is POSIX
configure:15880: /usr/bin/gcc -std=gnu99 -o conftest -ggdb3 conftest.c -ldl
5
+ eval '$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
On 09/21/12 11:14, David A. Wheeler wrote:
2. If the GNU standards stay as-is, the autotools need to make this easy to
do,
And that is easy to do. Just bundle up the configured substitutions into a
macro a la adding this to Makefile.in:
WHATEVERINAMEDIT = \
prefix=@prefix@ \
[...]
On 09/19/12 11:03, Russ Allbery wrote:
... I believe the method using sed is
correct, and generating the file at Autoconf time is not as correct...
For my perspective, there really ought to be a simple macro that just
exports all the configured values to whatever external command anyone
wants
On 08/09/12 14:09, Stefano Lattarini wrote:
It seems that AM_PROG_CC
Huh? There is no such think like 'AM_PROG_CC'. I guess you mean
AC_PROG_CC.
Yes, thank you. Wrong forum, too. (autoconf not automake)
How can -Wall cause the compiler to die? Have you added -Werror to
$(AM_CFLAGS)
Let's see if these are the right lists
It's partly autoconf because autoconf stages dummy dependency files
so the make include function won't choke. It is partly make because
I find it a bit tricky getting the dependencies just right. It is,
I think, mostly an automake question since I
Why AM_PROG_LEX and yet AC_PROG_YACC?
Could we not just add AC_PROG_LEX and AM_PROG_YACC aliases,
just to be nice? It seems a little extreme to be forced
to remember which use AM prefixes and which use AC prefixes.
It makes responsibility clearer, but still.
If you accidentally leave a newline character at the end of your
version string, the error message you get is file name argument required.
It takes some futzing around to figure out the real problem.
Either accommodating it or giving a helpful error message would be nice.
Thank you!
Regards,
On 06/16/11 14:31, Jack Kelly wrote:
It might be better to have config.h do something like this:
#ifdef CONFIG_H
# error config.h included twice
#endif
#define CONFIG_H
Warning: Quite a few misbehaving packages actually install their config.h.
It might be better to have an autoconf macro,
I was trying to chase down some still-hanging-around warnings.
This warning is insufficiently clear because I *do* have AC_LANG_SOURCE:
configure.ac:139: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
On 04/06/11 11:26, Bruce Korb wrote:
I was trying to chase down some still-hanging-around warnings.
This warning is insufficiently clear because I *do* have AC_LANG_SOURCE:
Never mind. This has become an irreproducible result.
Without knowing what I've done differently (something, surely
On 01/03/11 10:56, Eric Blake wrote:
Also, if such
complexity is required, perhaps an autoconf macro a la:
AC_ESYSCMD_OK([./git-version-gen .tarball-version])
that will error out of the command exits non-zero?
Now that's a nice idea! I'd rather name it m4_esyscmd_ok (and a
counterpart
On 12/31/10 08:06, Eric Blake wrote:
On 12/30/2010 06:37 PM, Bruce Korb wrote:
Hi,
Is this fatal? If so, how come it continued?
It's fatal to git-version-gen, which did not continue.
git-version-gen has but two fatal conditions: invalid arguments
yielding a usage message and an unreadable
On 12/31/10 08:06, Eric Blake wrote:
the configure.ac file starts with this:
AC_INIT([GNU libposix],
m4_esyscmd([./git-version-gen .tarball-version]),
[bug-gnu...@gnu.org])
Also, you should patch configure.ac to add an additional line:
m4_if(m4_sysval, [0], [],
Hi Jonathan,
On Sun, Jan 2, 2011 at 10:34 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Were you been able to reproduce that outside the script?
No, I was blind to the invocation. You found it. I was looking
without seeing. Thank you.
Given that shells without functions can be considered
Hi,
Is this fatal? If so, how come it continued?
If not, then why does it say, fatal?
What is really wrong? This looks like it is trying to extract
a git version and fiddle something, but is not doing it correctly.
I do not think that a git version should be at issue and
here is the line from
Hi Andy, Ralf, et al.,
On Mon, Dec 20, 2010 at 6:23 AM, Andy Wingo wi...@oblong.com wrote:
How much understanding of the machinery should be expected
of the hapless project builder?
I'm not sure, but: .
I am sure of this: It needs to be minimized. If there are insurmountable
Howdy,
It is feeling like circular responsibilities to me.
So far, the circle seems unbroken. Let's start by
enumerating the ways of breaking it and then, perhaps,
figure out the easiest way. Currently, it is actually
broken by users having to know that for a particular
distribution, they have
On 12/20/10 09:11, Nick Bowler wrote:
On 2010-12-20 08:54 -0800, Bruce Korb wrote:
If the default build is 64 bit, why does it make sense that the
default library directory is the 32 bit library?
As far as I know, the only reason for this design is to avoid breaking
32-bit proprietary
On 12/20/10 11:20, Ralf Wildenhues wrote:
* Bruce Korb wrote on Mon, Dec 20, 2010 at 03:09:48PM CET:
How much understanding of the machinery should be expected
of the hapless project builder?
I've skimmed most of the conversation in this thread now.
The crucial part, I think
Hi,
This is a request for information. The question is wy down
at the bottom. Sorry.
The only .m4 file I explicitly choose to install is autoopts.m4
for use by autoopts clients to check for proper version and
installation. Gary wrote the thing years ago and it hasn't
been touched since.
Hi Eric,
Thank you. automake list folks -- the main question is
Why are .m4 files being installed and how can I prevent it?
Original Message
Subject: [Bug 347095] sys-devel/autogen installs colliding \
m4 macros which break random packages
Clear-Text:
Hi,
On Sat, Sep 18, 2010 at 10:57 AM, Bruce Korb bk...@gnu.org wrote:
Hi Bruno,
On Wed, Sep 15, 2010 at 11:18 AM, Bruno Haible br...@clisp.org wrote:
Have you tried to follow the approach of
http://www.gnu.org/software/gnulib/manual/html_node/POSIX-Substitutes-Library.html?
I have now
Hi Matěj,
On Wed, Apr 28, 2010 at 1:48 PM, Matěj Týč matej@gmail.com wrote:
I am quite sure that one .tpl and .def tuple can result in multiple
files, all of them having the same basename, but possibly different
extensions.
The template defines what files get output. It is entirely
Alfred M. Szmidt wrote:
Bruce, how about this? I'd actually rather see the whole version.m4
mess be removed, but this is a decent fix for now.
A good and proper define-in-one-place fix for version stamps
is a really good idea. Sticking the original version string
into an AC_INIT() m4 macro is
Without some clear marker, it is more than a little hard to find.
This is line 414 of 619 lines of typescript text:
configure.ac:9: version `sharutils_version' doesn't follow Gnits standards
that includes 140 lines of warning messages all caused by gnulib
macros. By the way, I didn't find
Hi Karl,
Just an FYI: re-rolling sharutils is going to take real work.
The autotools have been improved a lot, so the macros that were
used are now broken. Though the build log says to run autoupdate,
I did that and still had these results. It may be a while before
I plod my through all the
On Wed, Sep 3, 2008 at 12:45 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello,
is this nice little Bourne shell quirk already known?
$ for i in 1 2 3 ; do : x$i; done
$ ls
x1
It works when I use 'echo' instead of ':'.
Seen with Solaris 10 sh, but also some other old shells IIRC.
Are
On Tue, May 13, 2008 at 12:16 PM, Bob Friesenhahn
[EMAIL PROTECTED] wrote:
Quite simple. I use a namespace-scoped name for the publically installed
config.h. I also use namespace-scoped defines in the publically installed
config.h. This is much simpler than the various complex substitution
Hi Paul,
I do hate contributing to this thread, but way back at the beginning,
I believe I remember that his irritation began with with some indecipherable
command not found message. I found the same thing quite frustrating.
I also complained (somewhat more politely :), and now Ralph has
Hi Ralf,
On Sun, Mar 16, 2008 at 5:26 AM, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Thanks for the report, and sorry for the long delay. Here's a cheap
patch. Would this be sufficient? It requires you to use -v aka.
--verbose in order to see the message.
[...]
Anyway, the
I need to use libffi for some work I am doing. It seemed like
it ought to be pretty simple: just run the autoconfigure bootstrapping
programs, configure and build. No such luck using this script in the
libffi subdirectory of GCC:
#! /bin/sh
libtoolize --force --copy
aclocal
autoheader
Hi,
I don't necessarily know that it is a gettext program.
I certainly don't want to have to know. Can this please
trigger a message that says, your distro packager left
out the gettext stuff, so you are hosed. It's easier
to cope with messages like that. Thank you.
- Bruce
P.S. it is the
On 8/29/07, Eric Blake [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
The short question I have is:
If automake/autoconf use GPLv3, will I be able to use them for packages
that are NOT GPLv3?
The goal is YES. Remember, with autoconf 2.61 and automake 1.10, both
packages
On 6/28/07, Brett Smith [EMAIL PROTECTED] wrote:
Dear GNU Maintainers,
Very soon the FSF sysadmins will freeze software uploads to the GNU FTP
site. You will still be able upload new files at your convenience, but
for now they will not be processed and published. The system will begin
running
The index and search of the docs only yields this:
`AM_PROG_CC_C_O'
This is like `AC_PROG_CC_C_O', but it generates its results in the
manner required by automake. You must use this instead of
`AC_PROG_CC_C_O' when you need this functionality, that is, when
using per-target
Hi Paul,
On 3/26/07, Paul Eggert [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] Shell Pattern Matching
[EMAIL PROTECTED] Shell Pattern Matching
[EMAIL PROTECTED] Shell pattern matching
+
+Nowadays portable patterns can use negated character classes like
[EMAIL PROTECTED] The older syntax
Hi Paul,
On 3/26/07, Paul Eggert [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] Shell Pattern Matching
[EMAIL PROTECTED] Shell Pattern Matching
[EMAIL PROTECTED] Shell pattern matching
+
+Nowadays portable patterns can use negated character classes like
[EMAIL PROTECTED] The older syntax
Not knowing the guts of this, my only complaint has to do
with the help text for ``--clean'' and the lack of consistency
WRT ``-c'' being an acceptable alias for it.
Benoit Sigoure wrote:
Index: autoconf/bin/autoconf.as
===
RCS
Benoit Sigoure wrote:
Quoting Bruce Korb [EMAIL PROTECTED]:
Not knowing the guts of this, my only complaint has to do
with the help text for ``--clean'' and the lack of consistency
WRT ``-c'' being an acceptable alias for it.
Yeah you're right, the message should be consistent
I don't agree with this point. There is a substantial number of
application developers who would prefer -failsafe. There is a
substantial number who would prefer -frisky. We don't know which set
is larger. We get a lot of bug reports about missed optimizations.
six vs. half a dozen.
Paul Eggert wrote:
I don't feel a strong need for 'configure' to default to
-fstrict-aliasing with GCC. Application code that violates
strict aliasing assumptions is often unportable in practice
for other reasons, and needs to be rewritten anyway, even if
optimization is disabled. So
Hi Stepan,
On 11/28/06, Stepan Kasal [EMAIL PROTECTED] wrote:
On Mon, Nov 27, 2006 at 08:26:20AM -0800, Bruce Korb wrote:
In this case, truth is, I don't think wchar.h requires runetype.h,
but rather wint_t type *normally* requires wchar.h but, for OS/X,
it instead requires runetype.h.
well
On 11/26/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Bruce Korb wrote on Mon, Nov 27, 2006 at 02:40:07AM CET:
Trying to make sure I'm tracking what is meant:
# --
# check for various programs used during the build
Hi Ralf,
Ralf Wildenhues wrote:
What is unclear about the following, quoting from
http://www.gnu.org/software/autoconf/manual/html_node/Present-But-Cannot-Be-Compiled.html
?
| The proper way the handle this case is using the fourth argument
| (see Generic Headers):
|
| $ cat configure.ac
Hi Tomaz(,
Tomaz( Slivnik wrote:
I just tried compiling autogen 5.8.7 on Mac OS X 10.4.8.
During ``configure'' I receive the following output:
configure: WARNING: wchar.h: present but cannot be compiled
configure:
On 11/7/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
The issue in question:
https://sourceforge.net/tracker/?func=detailatid=103593aid=1591697group_id=3593
should be fixed by the patch below. On the way I stumbled over more
possible issues (in autogen and its dependencies), none of which seem
On 11/7/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
The issue in question:
https://sourceforge.net/tracker/?func=detailatid=103593aid=1591697group_id=3593
should be fixed by the patch below. On the way I stumbled over more
possible issues (in autogen and its dependencies), none of which seem
One of my clients is seeing this 8 character weirdism in all
of the substitution expressions, rendering the configured files
all completely broken. I've not seen it before and don't know
how it happens. Any hints? Thanks - Bruce
___
Autoconf
Paul Eggert wrote:
Bruce Korb [EMAIL PROTECTED] writes:
One of my clients is seeing this 8 character weirdism in all
of the substitution expressions, rendering the configured files
all completely broken. I've not seen it before and don't know
how it happens. Any hints? Thanks - Bruce
Paul Eggert wrote:
This macro does not work when the headers #define sigsetjmp to
something else.
Since sigsetjmp might be a macro without a function but might be a
function, which is a bit unusual, I suggest #if defined sigsetjmp ||
HAVE_SIGSETJMP.
Hi Paul,
Thank you. Clearly, for
This macro does not work when the headers #define sigsetjmp to
something else. I'm not finding the right alternative.
Thanks - Bruce
+ gcc -o conftest -g -O2 conftest.c -ldl
/net/simpsons/export/ws/ws0/bkorb/tmp/ccZ30ygl.o: In function `main':
/local/src/ag/autogen-5.8.5pre99/_b/conftest.c:79:
This macro does not work when the headers #define sigsetjmp to
something else. I'm not finding the right alternative. Should the
macro be enhanced, or is one expected to know ahead of time that
sigsetjmp might be a macro and use a different autoconf macro?
Thanks - Bruce
+ gcc -o conftest -g
Andreas Schwab wrote:
Thomas Dickey [EMAIL PROTECTED] writes:
btw - does AC_CHECK_FUNCS(stat) work? stat() is required to be a
function.
Yes, but many libcs are buggy.
not required to be a normal function implies that it is
common knowledge that everybody knows you have to roll your
own
Eric Blake wrote:
not required to be a normal function implies that it is
common knowledge that everybody knows you have to roll your
own AC macro?
Have you tried AC_CHECK_DECLS instead? You really are checking
whether sigsetjmp is declared and you can compile with it, not
whether it is a
I was thinking however to another solution that may work and be lighter
: instead of |using AC_OUTPUT_COMMANDS| or *AC_CONFIG_COMMANDS* to
generate a pre-cooked unconditional list of includes (thus removing the
needs of exposing config.h), one may just ensure that symbols in this
last file
Bob Friesenhahn wrote:
This is the approach I use for my own package:
1) Two different configuration headers are generated from configure.ac:
AC_CONFIG_HEADERS([magick/magick_config.h magick/magick_config_api.h])
the second one uses a hand-maintained template (derived from the primary
one)
Laurence Darby wrote:
Hi,
I'm just starting to learn autotools, so far I've tried about 1/4 of
4 tutorials, without much success. Then I RTFM, and overall it's
surprisingly good :)
Starting from scratch, I ran autoscan, but it gave an error message:
autom4te: configure.ac: no such file or
Olivier Boudeville wrote:
After having tried this approach, I noticed that at least AC_INIT,
AC_CONFIG_SRCDIR and AC_CONFIG_HEADERS do not seem to allow variable
substitution ($A taken litterally instead of its value, am I wrong ?)
I think to using a template that could be filled with
Ralf Wildenhues wrote:
OK, thanks. I have applied the following patch to fix these issues,
assuming silent agreement to the other part of my proposed change. ;-)
Looks good to me! Thank you.
Completely off-topic:
Now, I have a curiosity question. Why this (unchanged) construct:
test
Ralf Wildenhues wrote:
Which system are you on? Where is mktemp(1) from?
This is the crux of the issue: ``Where is mktemp(1) from?''
The code assumes that:
f=`mktemp -d -q x`
leaves the environment variable f containing the name of the
directory. mktemp(1) is not a well-established
Ralf Wildenhues wrote:
* Bruce Korb wrote on Wed, Jan 11, 2006 at 06:15:58PM CET:
Ralf Wildenhues wrote:
Which system are you on? Where is mktemp(1) from?
This is the crux of the issue: ``Where is mktemp(1) from?''
The code assumes that:
f=`mktemp -d -q x`
leaves the environment
Harlan Stenn wrote:
For packages that are big enough (ie, that have a large/slow run of
configure), this is an unnacceptable solution.
Even small packages with few needs beyond what ought to be simple, vanilla
POSIX stuff require monsterous configs. Isn't everything big enough? :)
Bob Friesenhahn wrote:
On Mon, 19 Dec 2005, Bruce Korb wrote:
Harlan Stenn wrote:
For packages that are big enough (ie, that have a large/slow run of
configure), this is an unnacceptable solution.
Even small packages with few needs beyond what ought to be simple,
vanilla
POSIX stuff
Daryl Lee wrote:
Hi Daryl,
There are two conventions generally available:
${package}-config cflags ; ${package}-config link|ldflags
. More recently, pkg-config
And, of course, if no ${package}.pc file exists, I'm out of luck, yes?
out of luck? Writing config macros aren't the
Daryl Lee wrote:
I am autoconfiscating a project involving other developers. I need a
portable way of finding a header (it's an OpenGL header, glut.h, but
that's just a specific example). On my machine, it's
in /usr/include/GL, but on other machines it may be elsewhere,
like /usr/include. The
As is typical, I press send and suddenly something dawns on me:
4. Because these tools wind up leaving their temporary directories
around, you get the error message:
autoreconf: Leaving directory `.'
autoreconf: cannot empty /local/tmp/ar8810.11683: Is a directory
$
The other variation on mktemp uses illegal option
(you get arrested if you use one). BTW, if the mktemp -d -q
is successful in creating a file, shouldn't you remove the
file before trying another method?
$ cvs diff -u ./lib/Autom4te/General.pm
Index: ./lib/Autom4te/General.pm
Keith Marshall wrote:
On Tuesday 25 October 2005 3:45 pm, Brian wrote:
Great thanks for the tips. I see its a bit chicken and egg, but is there a
reason config.h couldn't just define HAVE_CONFIG_H?
Because your source file is expected to use logic like this:--
#ifdef HAVE_CONFIG_H
I accidentally created my build subdirectory as SunOS-i86pc instead
of _SunOS-i86pc and the consequence was a mess:
$ cd SunOS-i86pc
$ ../configure --prefix=$HOME --bindir=$HOME/$BINDIR \
--libdir=$HOME/$LIBDIR CC=$(which cc)
ln: cannot create SunOS-i86pc/agen5/test/expr.test: No such file
Eric Lemings wrote:
This could very well be a FAQ but I was just wondering if there is some
conventional way to break a large configure.ac file down into smaller
modules, tests, sections, etc.
By defining your own macros. You could pretty much wrap your entire
configure.ac in:
Gary V. Vaughan wrote:
The style that fulfills goals 1 and 2 here is like this:
[...
# Found it, now check the version.
]AC_MSG_CHECKING([version of bison])[
...
]AC_MSG_RESULT([$ac_prog_version])[
...]
I.e. put braces around everything, but unbrace the macro invocations
Hi all,
sharutils contains a file named, m4/xstrtoimax.m4 and autoreconf is
invoked thus:
autoreconf --force --install --include=m4 -Wall
configure.ac contains a line: jm_AC_PREREQ_XSTRTOIMAX, and so does the
resulting configure file, yielding the error message:
configure.ac:98: error:
B.W.H. van Beest wrote:
High,
Did you ever found the solution to the problem described in the Subject
field?
I am having the same problem, have googled to find find the solution,
but found none that I understood.
Hi Bertwim,
You shoud find a dozen or so hits if you add a space in the string
On Friday 11 March 2005 08:49 am, Sam Steingold wrote:
* Bruno Haible [EMAIL PROTECTED] [2005-03-11 17:31:51 +0100]:
Sam Steingold wrote:
But this one works:
AC_INIT
AC_CONFIG_SRCDIR(foo.c)
. $srcdir/version.sh
AM_INIT_AUTOMAKE(my package, $VERSION_NUMBER)
It would
On Tuesday 25 January 2005 01:47 pm, Alexandre Duret-Lutz wrote:
$ autoreconf
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
AM_GNU_GETTEXT_VERSION
1. The automake example of AM_GNU_GETTEXT does not show
AM_GNU_GETTEXT_VERSION being used in conjunction with
That section says:
Many packages come with a script called `bootstrap.sh' or
`autogen.sh', that will just call `aclocal', `libtoolize', `gettextize'
or `autopoint', `autoconf', `autoheader', and `automake' in the right
order. Actually this is precisely what `autoreconf' can do for you.
On Sunday 30 January 2005 03:53 pm, Andreas Schwab wrote:
Bruce Korb [EMAIL PROTECTED] writes:
In fiddling with sharutils, I discovered that it is too early to encourage
the dropping of bootstrap scripts just yet. autoreconf does not provide
a way of convincing automake to run
On Tuesday 25 January 2005 01:37 am, Noah Misch wrote:
On Sun, Jan 23, 2005 at 09:28:36AM -0800, Bruce Korb wrote:
$ autoreconf
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
AM_GNU_GETTEXT_VERSION
1. The automake example of AM_GNU_GETTEXT does not show
$ autoreconf
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
AM_GNU_GETTEXT_VERSION
autoreconf: cannot empty /tmp/ar0.4849: Is a directory
$ find /tmp/ar0.4849
/tmp/ar0.4849
/tmp/ar0.4849/am4tu48Whq
/tmp/ar0.4849/am4tCpTneD
/tmp/ar0.4849/am4tiZINdq
/tmp/ar0.4849/ahAqZXRx
On Friday 31 December 2004 03:20 pm, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The autoconf manual mentions nothing about the limitations of $(( ))
arithmetic expansion, other than the fact that $( ) command substition can
be confused with it when using subshells.
On Thursday 30 December 2004 08:19 pm, J.T. Conklin wrote:
Roger Leigh's AC_CONFIG_PKGCONFIG_IN macro from the autoconf macro
archive generates a *.pc.in files. The intent seems to be for the
*.pc.in file to be post-processed by AC_CONFIG_FILES to expand any
@macros@, and then the resulting
case $ac_config_target in
# Handling of arguments.
Makefile ) [[]] ;;
*) { { echo $as_me:$LINENO: error: invalid argument: $ac_config_target 5
echo $as_me: error: invalid argument: $ac_config_target 2;}
{ (exit 1); exit 1; }; };;
If I want to apply the configure
On Monday 20 December 2004 01:48 am, Paul Eggert wrote:
Akim Demaille [EMAIL PROTECTED] writes:
Underpinning this is the idea that long examples should be GPL'd, as
opposed as are de facto as of today. Why should they?
Well, let's be concrete about this and take one example from
On Monday 20 December 2004 11:23 am, Paul Eggert wrote:
Bruce Korb [EMAIL PROTECTED] writes:
Piffle. It is a trivial example.
Well, it doesn't really matter what you or I think is trivial: what
counts is what a federal judge would think (in the US, anyway).
It would be difficult
On Sunday 19 December 2004 08:49 am, Bob Friesenhahn wrote:
On Sun, 19 Dec 2004, Alexandre Duret-Lutz wrote:
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.
1 - 100 of 192 matches
Mail list logo
