On 17 Dec 2024, at 18:23, Zack Weinberg wrote:
> The other thing that comes to mind is, if there were anyone working
> seriously on usage of autoconf *without* automake, that would make
> the move a lot more valuable. I know some people have tried that in
> the past but I don't think any of them
On Tue, Dec 17, 2024, at 12:24 PM, Ross Burton wrote:
> On 17 Dec 2024, at 17:17, Nick Bowler wrote:
>> Adding the automake list, because (mostly for historical reasons)
>> aclocal is actually part of automake, not autoconf.
>
> I’ve been using autotools for too many years
On 17 Dec 2024, at 17:17, Nick Bowler wrote:
> Adding the automake list, because (mostly for historical reasons)
> aclocal is actually part of automake, not autoconf.
I’ve been using autotools for too many years and I _still_ forget what tool is
where… Though considering what it do
Hi Ross,
Adding the automake list, because (mostly for historical reasons)
aclocal is actually part of automake, not autoconf.
On 2024-12-17 11:01, Ross Burton wrote:
> I’m trying to clean up our autoconf invocation and want to do things
> the “right” way.
>
> We’re in a cross envi
Bruno Haible wrote:
Jacob Bachmeyer wrote:
Another related check that /would/ have caught this attempt would be
comparing the aclocal m4 files in a release against their (meta)upstream
sources before building a package. This is something distribution
maintainers could do without
Hi Zack,
*automake* can exit with code 63 under
some circumstances, but it really looks like aclocal never will.
Agreed. I searched for "63" in automake distributions back to 1.11.3, as
well as the current sources, and no trace of any 63's in aclocal, only
in automake.
One of Autoconf's regression tests includes:
# If Autoconf is too old, or the user has turned caching off, skip:
AT_CHECK([aclocal || { ret=$?; test $ret -eq 63 && ret=77; exit $ret; }],
[], [], [ignore])
The effect is to skip the rest of the test if aclocal's exit
Hello Karl,
Mathieu Lirzin writes:
> Karl Berry writes:
>
>> Other than that, please push asap! --thanks again, karl.
>
> I Will push that patch before the end of the week.
Done in commit f19ecc089b017d0f0cde1e960fb1a6a407005164.
Thanks for the review.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B
Hello Karl,
Karl Berry writes:
> Hi Mathieu - I'm glad you replied. I saw in the ChangeLog that you
> created AUTOMAKE_UNINSTALLED :). The general idea was clear, but all the
> implications, not so much.
>
> Here is a patch that seem to fix the issue, I have added some clutter to
> AM_TE
Hi Mathieu - I'm glad you replied. I saw in the ChangeLog that you
created AUTOMAKE_UNINSTALLED :). The general idea was clear, but all the
implications, not so much.
Here is a patch that seem to fix the issue, I have added some clutter to
AM_TESTS_ENVIRONMENT
Thanks! make distcheck now
Hello Karl,
Karl Berry writes:
> The aclocal-print-acdir.sh test fails at the make installcheck step of
> make distcheck (it succeeds in the normal make check, and it succeeds at
> the make check of make distcheck; only fails in the make installcheck).
>
> This is because AUTOM
On Mon, Feb 3, 2020 at 6:23 PM Karl Berry wrote:
> The aclocal-print-acdir.sh test fails at the make installcheck step of
> make distcheck (it succeeds in the normal make check, and it succeeds at
> the make check of make distcheck; only fails in the make installcheck).
>
>
The aclocal-print-acdir.sh test fails at the make installcheck step of
make distcheck (it succeeds in the normal make check, and it succeeds at
the make check of make distcheck; only fails in the make installcheck).
This is because AUTOMAKE_UNINSTALLED is (correctly) set in the
environment at
gt; (0r36:PYTHON_+1) != (0*4)
>>>> autom4te-2.69: /usr/bin/m4 failed with exit status: 1
>>>> aclocal-1.16: error: echo failed with exit status: 1
>
> Looks like the reversion of 1d60fb72168e62d33fe433380af621de64e22f23
> has fixed this problem and I can build my
4te-2.69: /usr/bin/m4 failed with exit status: 1
>>> aclocal-1.16: error: echo failed with exit status: 1
Looks like the reversion of 1d60fb72168e62d33fe433380af621de64e22f23
has fixed this problem and I can build my projects again.
Is there an ETA for a point release containing this fix?
Cheers
Adam
ptsetup/blob/master/configure.ac#L506
> https://github.com/ImageMagick/PythonMagick/blob/master/configure.ac#L42
>
> doesn't work anymore:
>
>> * aclocal *
>> * PWD: /var/tmp/portage/sys-fs/cryptsetup-2.0.1/work/cryptsetup-2.0.1
>> * aclocal -I m4
>>
ork anymore:
> * aclocal *
> * PWD: /var/tmp/portage/sys-fs/cryptsetup-2.0.1/work/cryptsetup-2.0.1
> * aclocal -I m4
>
> /usr/bin/m4:configure.ac:506: bad expression in eval (bad input): ($+1) != (2)
> /usr/bin/m4:configure.ac:506: bad expression in eval (bad input)
On Tuesday 08 of December 2015, Arkadiusz Miśkiewicz wrote:
> On Tuesday 08 of December 2015, Eric Blake wrote:
> > Huh - it sounds like your version of perl is trying to open a literal
> > file named 'echo ... | autom4te ... autoconf.ac |' , instead of properly
> > opening a subshell command that
On Tuesday 08 of December 2015, Eric Blake wrote:
> Huh - it sounds like your version of perl is trying to open a literal
> file named 'echo ... | autom4te ... autoconf.ac |' , instead of properly
> opening a subshell command that feeds echo to autom4te then collects the
> output of autom4te (basi
[not really an m4 problem, so future replies can be to just automake]
On 12/08/2015 02:51 AM, Arkadiusz Miśkiewicz wrote:
>
> Hello.
>
> Using
> m4 (GNU M4) 1.4.17
> automake (GNU automake) 1.15
>
> /usr/bin/aclocal contains code:
>
> $traces .= " --l
Hello.
Using
m4 (GNU M4) 1.4.17
automake (GNU automake) 1.15
/usr/bin/aclocal contains code:
$traces .= " --language Autoconf-without-aclocal-m4 ";
$traces = "echo '$early_m4_code' | $traces - ";
...
verb "running $traces $configure_ac";
my
Never mind.
Diego is right. This file pkg.m4 is not part of automake but part of the
pkg-config package. Running "sudo apt-get install pkg-config" installs this
m4 file (not sure if the version of aclocal matters at all).
Thanks Peter and Diego for helping!
- Gao
On Wed, Mar 26, 2014
On 03/26/2014 08:41 AM, Yunzhong Gao wrote:
Hi all,
I was trying to install automake 1.14 on Ubuntu 13.10 which comes with
automake 1.13 pre-installed. I appear to be missing this file
/usr/share/aclocal/pkg.m4. Is this file
auto-generated by the configure-make-install process, or is it to be
comes with
> automake 1.13 pre-installed. I appear to be missing this file
> /usr/share/aclocal/pkg.m4. Is this file
> auto-generated by the configure-make-install process, or is it to be
> downloaded from
> somewhere? Many many thanks in advance,
> - Gao
>
Hi all,
I was trying to install automake 1.14 on Ubuntu 13.10 which comes with
automake 1.13 pre-installed. I appear to be missing this file
/usr/share/aclocal/pkg.m4. Is this file
auto-generated by the configure-make-install process, or is it to be
downloaded from
somewhere? Many many thanks in
> AC_CONFIG_MACRO_DIRS is the one you want to use (plural form).
Thanks. I wasn't aware that it exists (since it is missing in the
autoconf 2.69 documentation). I now see that it is mentioned in
automake, but the macro's prefix `AC_' didn't make me look it up
there.
Werner
Hi Diego, thanks for chiming in.
On 06/22/2013 12:19 PM, Diego Elio Pettenò wrote:
> Hi Werner,
>
> AC_CONFIG_MACRO_DIR expects a single directory (it's used by among other
> libtool to put its m4 files).
>
> AC_CONFIG_MACRO_DIRS is the one you want to use (plural form).
>
> HTH
>
I think you'
7:27 PM, Werner LEMBERG wrote:
>
> [automake 1.14]
>
> It seems that there are problems if AC_CONFIG_MACRO_DIR contains more
> than a single directory. Calling
>
> aclocal -I gnulib/m4 --force -I m4
>
> within the attached bundle causes
>
> aclocal: error:
tags 13514 + patch
close 13514
stop
On 02/20/2013 10:11 PM, Stefano Lattarini wrote:
> On 02/18/2013 09:53 AM, Pavel Raiskup wrote:
>> Hi Stefano, thanks for refinements! I'm ok with these patches.
>>
> Good! I will push them tomorrow if I hear no objection by then.
>
Pushed now. I'm thus clos
On Wednesday 2013-01-09 22:27, Stefano Lattarini wrote:
>>
>> Now I just have to figure out why someone thought that openSUSE
>> should create the manpages directly...
>>
>Good question
>
>What happens if you do this instead?
>
>help2man -S FSF ./t/wr
On 01/09/2013 10:13 PM, Jan Engelhardt wrote:
> On Wednesday 2013-01-09 19:11, Stefano Lattarini wrote:
>
>> On 01/09/2013 05:05 PM, Jan Engelhardt wrote:
>>>
>>> The
>>>
>>> help2man: can't get `--help' info from ./aclocal
>>
On Wednesday 2013-01-09 19:11, Stefano Lattarini wrote:
>On 01/09/2013 05:05 PM, Jan Engelhardt wrote:
>>
>> The
>>
>> help2man: can't get `--help' info from ./aclocal
>>
>> error seems to have reappeared in automake-1.13.1 (judging fr
On 01/09/2013 05:05 PM, Jan Engelhardt wrote:
>
> The
>
> help2man: can't get `--help' info from ./aclocal
>
> error seems to have reappeared in automake-1.13.1 (judging from
> http://gnu-automake.7480.n7.nabble.com/Man-pages-for-automake-and-aclocal-td1
The
help2man: can't get `--help' info from ./aclocal
error seems to have reappeared in automake-1.13.1 (judging from
http://gnu-automake.7480.n7.nabble.com/Man-pages-for-automake-and-aclocal-td11966.html)
help2man is of version 1.40.12.
---
Executing(%build): /bin/sh -
here's no need to copy them
> (or m4_include them) into aclocal.m4, which is just an historical
> implementation
> detail of pre-2.13 autoconf... it will just load the macro definitions from
> wherever it finds them, and (optionally) copy them into
> AC_CONFIG_MACRO_DIR{,S}
Hi Stefano,
On 17 Oct 2012, at 16:45, Stefano Lattarini wrote:
> On 10/17/2012 11:24 AM, Gary V. Vaughan wrote:
>> On 17 Oct 2012, at 15:52, Stefano Lattarini
>> wrote:
>>> On 10/17/2012 10:25 AM, Gary V. Vaughan wrote:
>>>> I remember many years ago that T
autoconf-patches/2012-10/msg00018.html>
>>
>> On 10/17/2012 10:25 AM, Gary V. Vaughan wrote:
>>>
>>> [SNIP]
>>>
>>> I remember many years ago that Tom Tromey (IIRC) stated that aclocal
>>> was just a stop-gap measure until autoconf could fin
:
>>
>> [SNIP]
>>
>> I remember many years ago that Tom Tromey (IIRC) stated that aclocal
>> was just a stop-gap measure until autoconf could find it's own macros.
>>
>> I'd *really* like to see aclocal die as a separate program, and have
>
[Adding Automake list in CC:]
Reference:
<https://lists.gnu.org/archive/html/autoconf-patches/2012-10/msg00018.html>
On 10/17/2012 10:25 AM, Gary V. Vaughan wrote:
>
> [SNIP]
>
> I remember many years ago that Tom Tromey (IIRC) stated that aclocal
> was just a stop-gap m
27;
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal --force
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: adding subdirectory c++ to autoreconf
> autoreconf: Entering directory `c++'
> autoreconf: configure.ac: not using Libtool
&
Hi,
I just helped a co-developer who experienced a mysterious
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory c++ to autoreconf
autor
Hi Ralf, thanks for the report.
On 04/24/2012 11:45 AM, Ralf Corsepius wrote:
> Hi,
>
> automake >= 1.11.4 doesn't create $(datadir)/aclocal.
>
> This cause aclocal to fail:
>
> tar xvf automake-1.11.4.tar.xz
> cd automake-1.11.4
> configure --prefix=/tmp/fo
Hi,
automake >= 1.11.4 doesn't create $(datadir)/aclocal.
This cause aclocal to fail:
tar xvf automake-1.11.4.tar.xz
cd automake-1.11.4
configure --prefix=/tmp/foo
make
make install
Change to the source directory of an arbitrary automake-based package
and run
/tmp/foo/bin/aclocal
[removing automake-patches]
On 3/17/11 10:39 AM, Maynard Johnson wrote:
you aclocal calls. Also, in the next automake release, aclocal
will probably support a new 'ACLOCAL_PATH' environment variable
that would help solving this kind of problems
Well, you could always resort to add
On 03/17/2011 10:02 AM, Stefano Lattarini wrote:
On Thursday 17 March 2011, Maynard Johnson wrote:
On 03/17/2011 5:17 AM, Stefano Lattarini wrote:
Well, you could always resort to adding proper `-I' option to
you aclocal calls. Also, in the next automake release, aclocal
will probably su
On Thursday 17 March 2011, Maynard Johnson wrote:
> On 03/17/2011 5:17 AM, Stefano Lattarini wrote:
> > Well, you could always resort to adding proper `-I' option to
> > you aclocal calls. Also, in the next automake release, aclocal
> > will probably support a new
On 03/17/2011 5:17 AM, Stefano Lattarini wrote:
[adding automake-patches]
On Thursday 17 March 2011, Maynard Johnson wrote:
Hello,
I have installed a version of aclocal into /usr/local that's newer
than my distro's version (I needed a fix from the newer version).
But then I ran into
[adding automake-patches]
On Thursday 17 March 2011, Maynard Johnson wrote:
> Hello,
> I have installed a version of aclocal into /usr/local that's newer
> than my distro's version (I needed a fix from the newer version).
> But then I ran into a problem recently where the b
Hello,
I have installed a version of aclocal into /usr/local that's newer than my
distro's version (I needed a fix from the newer version). But then I ran into
a problem recently where the build of some package was failing because aclocal
was not finding the pkgcfg.m4 file in
; then
which occurs twice in GMP 5.0.1's ./configure, and once in aclocal.m4, so the
source seems to be automake's aclocal program. If you remove all occurrences of
the second test, the build works fine.
I have some test code at [1]. Note the WORKAROUND on line 232 - removing it
will caus
On 21/12/10 13:36, Stefano Lattarini wrote:
> The bug you're hitting must be located in a third-part macro, since no
> automake-provided macro do something similar to that. And in fact, it
> seems to come from GMP-5.0.1's own acinclude.m4 (which is *not* the same
> as aclocal.m4! see the automake
On 22/12/10 00:55, Peter Rosin wrote:
> FWIW, It smells exactly like a bug that was fixed in libtool 2.2.8 related
> to this NEWS entry:
I did some more poking around - this bug is in libtool, but not the one you
mention. The "responsible snippet" I pasted above is from libtool.m4, and it
exists i
On Thursday 28 October 2010, Stefano Lattarini wrote:
> On Wednesday 27 October 2010, Nick Bowler wrote:
> > On 2010-10-23 15:23 +0200, Stefano Lattarini wrote:
> > > Now I do. This happens because `aclocal', to find the includes in an
> > > input file, *grep*
On 11/17/2010 09:59 AM, Bruce Korb wrote:
>> Is it worth installing a temporary sed wrapper earlier in your PATH that
>> outputs debugging information such as the process id of its parent if it
>> detects that one of the arguments starts with -q?
>
> Next time I run into it. I unwound everything
On 11/17/10 07:35, Eric Blake wrote:
> On 11/17/2010 08:11 AM, Bruce Korb wrote:
>>> OK. I don't see where it should come from in Autoconf nor Automake.
>>> Any case the package at hand contains m4_esyscmd in configure.ac that
>> ^
>>> contains a
On 11/17/2010 08:11 AM, Bruce Korb wrote:
>> OK. I don't see where it should come from in Autoconf nor Automake.
>> Any case the package at hand contains m4_esyscmd in configure.ac that
> ^
>> contains a buggy sed script? If not, please state ex
On 11/16/10 23:28, Ralf Wildenhues wrote:
> * Bruce Korb wrote on Tue, Nov 16, 2010 at 10:18:50PM CET:
>> On 11/16/10 12:45, Ralf Wildenhues wrote:
>>> This comes probably from autoreconf, not from aclocal.
>> That is rather difficult to discern. Either way, the
>>
* Bruce Korb wrote on Tue, Nov 16, 2010 at 10:18:50PM CET:
> On 11/16/10 12:45, Ralf Wildenhues wrote:
> > This comes probably from autoreconf, not from aclocal.
> That is rather difficult to discern. Either way, the
> controlling program needs to say:
> "I was running t
On 11/16/10 12:45, Ralf Wildenhues wrote:
> This comes probably from autoreconf, not from aclocal.
That is rather difficult to discern. Either way, the
controlling program needs to say:
"I was running this script:\n%s\nAND:\n%s"
which might get wrapped again by autoreconf (or not
conf: configure.ac: not using Gettext
> > autoreconf: running: aclocal --force -I m4
> > sed: invalid option -- 'q'
> > Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
> >
> > -n, --quiet, --silent
> [.]
This comes probably from
What is it really trying to say?
I'm not a real perl expert.Thank you!
> $ autoreconf --force --install --verbose --symlink
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal --force -I m4
> sed: invalid o
Hello Ryan,
* Ryan Lortie wrote on Sat, Nov 13, 2010 at 05:49:57PM CET:
> I recently filed a bug against a freedesktop.org component because it
> didn't honour the ACLOCAL_FLAGS environment variable. That bug got
> closed, telling me to use ACLOCAL like so:
>
> ACLOCAL=&#x
On Saturday 13 November 2010, Ryan Lortie wrote:
> Hello,
Hello Ryan.
Just a quick partial reply ...
> [CUT]
> In my opinion, this is an argument for why ACLOCAL_FLAGS
> (or at least some ACLOCAL_PATH environment variable)
Supporting ACLOCAL_PATH is a good idea IMO -- and the nice thing about it
ocal/share/aclocal/. So my ACLOCAL_FLAGS contains
ACLOCAL_FLAGS="-I /home/desrt/local/share/aclocal"
and all GNOME packages pick this up (usually by explicit referencing of
this variable from our autogen.sh and Makefile.am).
(for example)
$ACLOCAL $ACLOCAL_FLAGS || exit $?
and
ACL
On 2010-11-04 20:47 +0100, Stefano Lattarini wrote:
> On Thursday 28 October 2010, Stefano Lattarini wrote:
> > On Wednesday 27 October 2010, Nick Bowler wrote:
> > > On 2010-10-23 15:23 +0200, Stefano Lattarini wrote:
> > > > So I think your first problem is "ju
On Thursday 28 October 2010, Stefano Lattarini wrote:
> On Wednesday 27 October 2010, Nick Bowler wrote:
> > On 2010-10-23 15:23 +0200, Stefano Lattarini wrote:
> > > So I think your first problem is "just" an aclocal limitation we should
> > > resign to liv
On Wednesday 27 October 2010, Nick Bowler wrote:
> On 2010-10-23 15:23 +0200, Stefano Lattarini wrote:
> > Now I do. This happens because `aclocal', to find the includes in an
> > input file, *grep* the file's content, looking for literal `m4_include'
> >
On 2010-10-23 15:23 +0200, Stefano Lattarini wrote:
> Now I do. This happens because `aclocal', to find the includes in an
> input file, *grep* the file's content, looking for literal `m4_include'
> (and similar), without analyzing m4 traces (not sure why aclocal acts
&
On Friday 22 October 2010, Nick Bowler wrote:
> On 2010-10-22 20:43 +0200, Stefano Lattarini wrote:
> > May I ask you that, the next time you report a problem, you also tell which
> > version of aclocal/automake are you using, and post the content of all the
> > relevant files
On 2010-10-22 20:43 +0200, Stefano Lattarini wrote:
> May I ask you that, the next time you report a problem, you also tell which
> version of aclocal/automake are you using, and post the content of all the
> relevant files (or reduced exemples thereof)? That would make it easier
&g
Hello Nick. Thanks for the report.
May I ask you that, the next time you report a problem, you also tell which
version of aclocal/automake are you using, and post the content of all the
relevant files (or reduced exemples thereof)? That would make it easier
for us to understand and reproduce
I'm trying to define an autoconf macro which calls m4_include on one of its
arguments. However, aclocal and/or automake seem to be choking a bit
when I do this. My first idea was to write something simple like the
following:
AC_DEFUN([MY_INC], [m4_include([$1])])
but this causes acloc
By the way, you may be interested in seeing how I was able to use
m4_define and still get aclocal to use my file for gnulib's AC_DEFUN_ONCE
replacement (coupled with an AC_REQUIRE([gl_00GNULIB]) in gnulib-common.m4):
http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/00gnulib.m4
; > reason. OK to apply?
>
> Yes, please.
Done, thanks; but see below.
> But given the recent thread about AC_DEFUN being able to
> hoist contents while m4_define does not, would it ever make sense to add a
> macro in the AC_ namespace that is equivalent to m4_define but st
xpected to never be the object
>>>> of an AC_REQUIRE directive, and macros required by other macros inside
>>>> arguments do not need to be expanded before this macro, then use
>>>> m4_define."
By the way, you may be interested in seeing how I was able to use
sense to add a
macro in the AC_ namespace that is equivalent to m4_define but still
traced by aclocal? Unfortunately, the name AC_DEFINE is already claimed.
>
> Note that AC_DEFUN is needed for aclocal.
>
> * doc/autoconf.texi (Coding Style): Public third-party macros
to be expanded before this macro, then use
>>> m4_define."
> ...
>>> Is this a bug in aclocal?
>> I don't think so. Do you think the quote is an encouragement not to use
>> AC_REQUIRE?
> Hmmm. No, I don't think it's an encouragement not to
acros required by other macros inside
arguments do not need to be expanded before this macro, then use
m4_define."
...
Is this a bug in aclocal?
I don't think so. Do you think the quote is an encouragement not to use
AC_REQUIRE? For public macros, I'd even vent
her macros inside
> arguments do not need to be expanded before this macro, then use
> m4_define."
>
> So the Autoconf manual is encouraging users to use m4_define, however,
> when I define a macro using m4_define in a .m4 file in the m4 directory
> of my project, aclocal
n use m4_define."
So the Autoconf manual is encouraging users to use m4_define, however,
when I define a macro using m4_define in a .m4 file in the m4 directory
of my project, aclocal ignores it by not m4_including it in the
generated aclocal.m4 file. It appears to require the use o
>> The problem I was recently trying to solve is this: if I change a
>> plug.in file, automake doesn't trigger a re-run of aclocal, et al, Like
>> I would like it to.
>
>> Next thing was to use sinclude to include the files (we had been using
>> builtin([incl
>> The problem I was recently trying to solve is this: if I change a
>> plug.in file, automake doesn't trigger a re-run of aclocal, et al, Like
>> I would like it to.
>
>> Next thing was to use sinclude to include the files (we had been using
>> builtin([incl
change a
> plug.in file, automake doesn't trigger a re-run of aclocal, et al, Like
> I would like it to.
> Next thing was to use sinclude to include the files (we had been using
> builtin([include],$1) because of bug in aclocal 1.8. I _obviously_ don't
> care about
plug.in file, automake doesn't trigger a re-run of aclocal, et al, Like
I would like it to.
First thing I tried was injecting a list of the found plug.in files into
top level CONFIGURE_DEPENDENCIES - but this only causes
automake/autoconf to be re-run, and not aclocal.
Next thing was to use si
s
diff --git a/ChangeLog b/ChangeLog
index c8dca18..c4ab037 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2008-10-24 Clinton Roy <[EMAIL PROTECTED]>
+
+ * bin/autoreconf.in (parse_args): Pass --include to aclocal.
+ * doc/autoconf.texi (autoreconf Invocation): Updates for above.
+
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding automake list]
According to Clinton Roy on 10/22/2008 5:45 PM:
Hello, Clinton,
> This patch makes autoreconf pass along -I arguments to aclocal, which
> is useful in cases
> where m4 files are installed in sensible, but non standa
ings that I like to be able to do but autoreconf
>> does not do currently:
>
> Most of which can be had, or at least worked around, by using the
> overriding environment variables AUTOCONF, LIBTOOLIZE, ACLOCAL,
> AUTOMAKE, no?
Yes, but at that point it will be easier to just call
but autoreconf
> does not do currently:
Most of which can be had, or at least worked around, by using the
overriding environment variables AUTOCONF, LIBTOOLIZE, ACLOCAL,
AUTOMAKE, no?
> * Many autogen.sh scripts I've seen try each of automake, automake-1.10,
> automake-1.9 automak
Behdad Esfahbod wrote:
> Reading autoreconf source right now. I may just switch to it if my testers
> tell me it works on OS X and msys.
Ok, I see the following things that I like to be able to do but autoreconf
does not do currently:
* Many autogen.sh scripts I've seen try each of automake, a
Ralf Wildenhues wrote:
> Hello again,
>
> * Behdad Esfahbod wrote on Tue, Sep 16, 2008 at 01:40:41AM CEST:
>> To use an m4/ dir one has to modify three places:
>>
>> * autogen.sh: add "-I m4" to their aclocal invocation (ok, I know
>> autoreco
Hello again,
* Behdad Esfahbod wrote on Tue, Sep 16, 2008 at 01:40:41AM CEST:
> To use an m4/ dir one has to modify three places:
>
> * autogen.sh: add "-I m4" to their aclocal invocation (ok, I know autoreconf
> prolly handles it),
Yes, it does. What k
2008/7/30, Ralf Wildenhues wrote:
> aclocal endless loops are a pain to debug. If you can go back to a
> known-good version (of configure.ac and *.m4 files), you may be able to
> bisect.
One of the many things that have already been tried is to comment out
the new macro invocations l
Hello,
* Yang Tse wrote on Wed, Jul 30, 2008 at 08:17:54PM CEST:
>
> Since I'm not sure if this is actually an automake or autoconf issue,
It's not clear from the bug report.
aclocal endless loops are a pain to debug. If you can go back to a
known-good version (of configure.a
Hello!
Since I'm not sure if this is actually an automake or autoconf issue,
and sure you can also help I'm also posting this here as well as on
the autoconf mailin-list. Excuse me if this bothers someone.
Last addition of some macros to the cURL (libcurl) project have
triggered
to have comments that should not
> appear in the generated files, such as the example in the manual.
That is a reasonable goal, but I think it's somewhat counter-intuitive that
aclocal -- which is a tool that deals exclusively with Autoconf macros --
behaves completely differently than Auto
Hi Peter,
* Peter Simons wrote on Sat, Apr 12, 2008 at 01:20:51PM CEST:
>
> It appears that aclocal strips those "# ..." comments while
> copying the macros into the generated aclocal.m4 file.
>
> I was wondering whether this behavior is intentional and,
> a
Hi,
the Autoconf Macro Archive distributes m4 source codes that
contain comment lines beginning with multiple '#' characters,
i.e. five of them, as in the following example:
http://autoconf-archive.cryp.to/acx_blas.m4
It appears that aclocal strips those "# ..." commen
build.
>
> When "autoreconf -f -v -i" gets called, I get:
> aclocal: macro `AM_PROG_MKDIR_P' required but not defined
[...]
>
> And "automake --version" says 1.7.1 (which appears to be quite old?).
Yes, I would just retry with a newer version. Install Automake
quot; gets called, I get:
aclocal: macro `AM_PROG_MKDIR_P' required but not defined
On reading the manual, it seems that autoupdate is used to correct this, so
I ran that and got this:
aclocal.m4:17: error: this file was generated for autoconf 2.61.
You have another version of auto
> Took another look at what's available in MacPorts. I see two things
> matching my search for libtool:
>
> libtool devel/libtool 1.5.24 GNU Libtool ...
> libtool-devel devel/libtool-devel 1.9f The GNU Portable ...
Woo hoo! Deactivating libtool-devel and activating
1 - 100 of 269 matches
Mail list logo
