Hello!
Thanks for this release.
announce-gen: NEWS: no matching lines for '1.18'
> The signature should match the fingerprint of the following key:
> pub rsa2048 2012-06-12 [SC]
> 17D3 311B 14BC 0F24 8267 BF02 0716 748A 30D1 55AD
> uid Karl Berry
>
It seems that the key used t
Hello!
Thanks for this release. It seems that the key used to sign the archive is
no longer the one from the automake group. Is it intentional ?
All the best,
Valentin Lefebvre
Linux Distribution Engineer - packager
Member of System Boot and Init team
SUSE Software Solutions Germany GmbH
56100
On Wed, Feb 26, 2025 at 12:53 AM Karl Berry wrote:
> This is to announce automake-1.17.90, a alpha release.
> See the NEWS below for a brief summary of changes.
>
> Download here:
> https://alpha.gnu.org/gnu/automake/automake-1.17.90.tar.gz
> https://alpha.gnu.org/gnu/automake/automake-1.17.9
On Sun, 2021-10-03 at 21:51 -0700, Jim Meyering wrote:
> Thanks to everyone who has contributed!
> The following people contributed changes to this release:
Thank you everyone for your contributions. All of us who depend on your
work are very grateful.
--
Kip Warner -- Senior Software Engineer
O
On Mon, 10 May 2021, aotto wrote:
./configure {CC=gcc -m32 -O2} --prefix=... --enable-shared --disable-static
--with-readline-includes=... {--with-readline-library=-L.../lib -lreadline}
--with-tcl=.../lib --with-tcl-includes=...
The above does not look good to me. It seems that you expect t
On 10.05.21 20:35, Thomas Jahns wrote:
What does
ldd libtclreadline.so
give?
Regards, Thomas
> ls -ald *readline*
-rw-r--r-- 1 dev1usr users 478680 29. Apr 22:28 libreadline.a
lrwxrwxrwx 1 dev1usr users 18 29. Apr 22:28 libreadline.so ->
libreadline.so.4.0
lrwxrwxrwx 1 dev1usr users
On 5/10/21 7:14 PM, aotto wrote:
To be honest I don't want to set the -rpath at all…
what I have :
#1 libtclreadline.so depend on libreadline.so
#2 everything is in the SAME directory
#3 the directory is already KNOWN to ld.so
> ls -ald *readline*
-rw-r--r-- 1 dev1usr users 478680 29. Apr 22:
On 10.05.21 15:10, Thomas Jahns wrote:
Hi,
you are confusing the -rpath /some/path option to libtool, which tells
libtool where a library will be installed and the
-Wl,-rpath,/some/other/path option to ld. If you replaced -rpath
.../lib by -Wl,-rpath,.../lib everything should work as expected
Hi,
you are confusing the -rpath /some/path option to libtool, which tells libtool
where a library will be installed and the -Wl,-rpath,/some/other/path option to
ld. If you replaced -rpath .../lib by -Wl,-rpath,.../lib everything should work
as expected. Also relative rpath values will probabl
additional info:
the file tclreadline is opened by dlopen, add adding -rpath to cct does
NOT affect the dlopen path:
> LD_DEBUG=all ./cct
38807:
file=/dev/shm/dev1usr/Compiler3.BUILD/lib/JavaKiller/exe/linuxi386/lib/libtclreadline.so
[0]; dynamically loaded by ./libtcl8.3.so [0]
On Sun, 19 Aug 2012, Stefano Lattarini wrote:
Under Solaris 10, I found that some fancy ksh-style syntax was
failing due to use of /bin/sh.
You mean in your test scripts, or in the Automake-provided driver
scripts? The latter would be an Automake bug, while the former would
be a user error: if
On Tue, Aug 14, 2012 at 06:57:02PM -0500, Bob Friesenhahn wrote:
> AC_INIT(m4_esyscmd([scripts/pkginfo.sh package_name]),
> m4_esyscmd([scripts/pkginfo.sh package_version]),
> m4_esyscmd([scripts/pkginfo.sh package_bugreport]))
>
> Unfortunately, the values passed to AC_INIT are ca
The script I intend to use to obtain package information is in the
GraphicsMagick repository and produces information gleaned from a
'version.sh' script which has the smarts to produce some obvious
variable names.
echo `./scripts/pkginfo.sh package_bugreport`
graphicsmagick-b...@lists.sourcefo
On Wed, 15 Aug 2012, Stefano Lattarini wrote:
AM_INIT_AUTOMAKE($PACKAGE_NAME,"${PACKAGE_VERSION}${PACKAGE_VERSION_ADDENDUM}",
' ')
The reason is because it avoids needing to edit configure.ac (a really stupid
practice)
I agree with this; with today's DVCS, it's very tempting (and IMHO useful)
Hi Bob, I managed to find your old message about "dynamically computing
package versions for Automake and Autoconf". Some initial comments
follows. I'm adding the Autoconf list in CC:, because I believe this
is an Autoconf issue more than an Automake one.
On 05/20/2012 12:59 AM, Bob Friesenhahn
[adding automake list in CC:]
Hi Cédric. Please note that questions about automake should be
sent to the automake list, not to the autoconf one. Thanks.
On Monday 26 September 2011, GAVA Cédric wrote:
> Dear all
>
> I am trying to pass -Wall option to AM_AUTOMAKE :
>
I guess you mean AM_INIT_A
On Wed, Feb 24, 2010 at 2:23 PM, Ralf Wildenhues wrote:
> The above looks ok to me. Since I cannot, from your description,
> exactly reproduce the code that caused the warning for you, I cannot say
> whether that was a problem.
>
> The code as above does not yet take care of adjusting SUBDIRS (an
Hello,
* NightStrike wrote on Wed, Feb 24, 2010 at 06:29:04PM CET:
> AC_MSG_CHECKING([whether to build the optional libraries])
> AC_ARG_WITH([libraries],
> [AS_HELP_STRING([--with-libraries=ARG],
> [Build the extra mingw-w64 libs, where ARG is one of libmangle,
> pseh, or all])],
> [],
>
Hi Brain,
Thanks alot. Though I posted this in wrong mailing list.
I appreciate your comments and time this is real helpful.
Many Thanks
Lalit Seth
> Date: Wed, 3 Sep 2008 15:04:08 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: autoconf@gnu.org
> Subject: Re: Aut
Lalit Seth wrote:
> I am trying to learn Autoconf and Automake tools. There are few queries I have
These are separate from gcc and each have their own list. I've set the
reply-to list to autoconf@ since nothing below is really automake
specific.
> a) When compile happens it always have -g and -
On 8/30/07, Bruce Korb <[EMAIL PROTECTED]> wrote:
> Something fuzzily along the lines that all code emitted by these tools
> are, by that action alone, released to the public domain with no licensing
> requirements or constraints whatever? After all, they are sufficiently
> convoluted that I certa
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, bo
Eric,
Sounds good - thanks very much!
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Harlan Stenn on 8/29/2007 8:59 PM:
> This is the first I've seen on this thread.
>
> I have heard that GPLv3 is viral/invasive.
No more so than GPLv2 was, and hopefully less so. That was part of the
reason GPLv3 went through such a long
This is the first I've seen on this thread.
I have heard that GPLv3 is viral/invasive.
The short question I have is:
If automake/autoconf use GPLv3, will I be able to use them for packages
that are NOT GPLv3?
IE, if GPLv3 is viral/invasive, I cannot use software covered by GPLv3
for most of t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 8/29/2007 3:13 PM:
> Hello Brett,
>
> Thanks for your reply.
Likewise.
>
> * Brett Smith wrote on Mon, Aug 27, 2007 at 09:47:18PM CEST:
> Not the only one, but for another stable release (1.10.1), I don't think
> muc
Hi Ralf.
It appears that I told a small lie, I actually had INSTALL and friends defined
as follows ;
INSTALL = /usr/bin/install -c
INSTALL_DATA = ${INSTALL} -m 644
INSTALL_PROGRAM = ${INSTALL}
INSTALL_SCRIPT = ${INSTALL}
INSTALL_STRIP_PROGRAM = ${SHELL} $(install_sh) -c -s
To answer one of your
Hello Craig,
* Craig Sanders wrote on Tue, Jun 19, 2007 at 07:39:11AM CEST:
>
> Thankyou for your prompt response to my two queries last week.
>
> I think I have solved my own problems. One of the problems was that I
> had defined the variable ;
>
> INSTALL = install -c -m 644
Above line is
Hi Ralf.
Thankyou for your prompt response to my two queries last week.
I think I have solved my own problems. One of the problems was that I had
defined the variable ;
INSTALL = install -c -m 644
in one of my Makefile.am files. The reason I did this was because I was trying
to implement a
Hema K <[EMAIL PROTECTED]> writes:
> configure.in:16: warning: AC_RUN_IFELSE was called before AC_GNU_SOURCE
Try calling AC_GNU_SOURCE before line 16.
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
hi
actually i want to compile(ie cross compile mutt) with mb-gcc(for the
microblaze processor and uclinux OS) instead of gcc.
so by studying the documentation of autoconf, i started by
(1) adding AC_CANONICAL_SYSTEM in configure.in
(2) adding AC_TRY_RUN(mb-gcc) in configure.in
(3) adding AC_
On Fri, Mar 04, 2005 at 12:40:33PM -0300, Hema K wrote:
>
> i am not able to figure out as to why automake is not working.
Because your 6-year-old version does not understand the new constructs
that have been introduced in this century. Upgrade.
___
A
Hello,
On Fri, Mar 04, 2005 at 12:40:33PM -0300, Hema K wrote:
> the following is present in configure.in
>
> AC_CONFIG_FILES([Makefile intl/Makefile [...]
> AC_CONFIG_FILES([Makefile])
OK, in this case there is no need to repeat. The first AC_CONFIG_FILES
is enough.
One more wild guess: is i
Hi,
On Wed, 2 Mar 2005 11:09:09 +0100, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> Hello,
>
> [the right list for this question would be automake@gnu.org, btw]
>
> On Wed, Mar 02, 2005 at 04:31:13PM -0300, Hema K wrote:
> > i have a problem even though i have Makefile.am
> > i am getting the follo
Hi,
On Wed, Mar 02, 2005 at 10:30:13AM -0600, David Mohr wrote:
> > I guess you don't have
> > AC_CONFIG_FILES(Makefile.in)
> > in your configure.{ac,in}
>
> AC_CONFIG_FILES(Makefile)
of course, I apologize for the misleading typo.
> couldn't find a definition for AC_CONFIG_FILES,
The
Hello,
[the right list for this question would be automake@gnu.org, btw]
On Wed, Mar 02, 2005 at 04:31:13PM -0300, Hema K wrote:
> i have a problem even though i have Makefile.am
> i am getting the following error when i do automake.
> [EMAIL PROTECTED]:~/mutt-1.4.2.1$ automake
> automake: no `M
Bruce Korb <[EMAIL PROTECTED]> writes:
> On Tuesday 25 January 2005 01:47 pm, Alexandre Duret-Lutz wrote:
>> ... Maybe the autoreconf documentation should point to the Gettext
>> manual. Care to patch the Autoconf manual?
>
> Below. :-)
Thanks. I rewrote it a bit, and added a proper cross refe
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 use
[snipping automake@ from cc:]
On Tue, Jan 25, 2005 at 09:09:30AM -0800, Bruce Korb wrote:
> On Tuesday 25 January 2005 01:37 am, Noah Misch wrote:
> > The message is not meaningful because this Never Happens :)
>
> Ah. Good. Then I didn't see it. :)
That is to say, this only happens by a bug
On Tuesday 25 January 2005 01:47 pm, Alexandre Duret-Lutz wrote:
> Bruce> Um, okay, but if automake is going to emit the message, then it only
> Bruce> makes sense (to me) that automake include the documentation.
>
> That would make sense to me too. However automake is not
> emitting the mess
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
Bruce> 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_VERSIO
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
> >
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
> AM_GNU_GETTEXT_VERSION being used in conjunction with it.
> I
Eric Sunshine <[EMAIL PROTECTED]> writes:
> Autoconf could, for example, publish a macro such as the following:
>
> AS_SELECT_SHELL([features], [action-if-found], [action-if-not-found])
I like this basic idea approach (though of course it would take some
hacking).
Regarding use of Zsh, is it not possible to add options to the SHELL
definition so that even if Zsh is the selected shell, it will properly
split arguments.
For example, in my Zsh manual page, I see that the -y option enables
SH_WORD_SPLIT so presumably
SHELL = /bin/zsh -y
should emulate the Bou
On Mon, 19 Apr 2004 21:01:58 +0200, Alexandre Duret-Lutz wrote:
> A suggestion was to always use `SHELL = /bin/sh' in Makefiles.
> I simply don't know how correct this is, because that's how it
> was in the past before Chris Provenzano changed it to what it is
> now. The reason for that change see
Hello.
Alexandre Duret-Lutz wrote:
[snip]
A suggestion was to always use `SHELL = /bin/sh' in Makefiles.
I simply don't know how correct this is, because that's how it
was in the past before Chris Provenzano changed it to what it is
now. The reason for that change seems to have been lost.
Because
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> I'd say it would be useful that @SHELL@ be the most POSIX compliant
> shell that does not require any configuration code (such as
> _AS_BOURNE_COMPATIBLE) to work. CONFIG_SHELL would allow shell that
> require such extra code.
Yes, I like this i
>>> "Eric" == Eric Sunshine <[EMAIL PROTECTED]> writes:
[...]
Eric> I can submit a patch to autoconf-patches to make
Eric> Autoconf's shell selection more backward-compatible with
Eric> earlier versions of Autoconf, however this raises another
Eric> issue. My interpretation of this thread is
On Sun, 18 Apr 2004, Eric Sunshine wrote:
> I can submit a patch to autoconf-patches to make Autoconf's shell selection
> more backward-compatible with earlier versions of Autoconf, however this
> raises another issue. My interpretation of this thread is that Autoconf's new
> shell selection behav
On Sun, 18 Apr 2004 13:08:54 -0500 (CDT), Bob Friesenhahn wrote:
> On Sun, 18 Apr 2004, Eric Sunshine wrote:
> > Can you apply the following manual edit to the configure script
> > (not the configure.ac file) and report if it fixes the problem?
> > In configure, find the line:
> > as_candidate_shel
On Sun, 18 Apr 2004, Eric Sunshine wrote:
>
> CVS Autoconf looks for a shell which supports functions and $LINENO.
> Apparently, your zsh satisfies those requirements, so Autoconf is happy with
> it.
>
> > Even if zsh is used, there are well-documented ways to tell Zsh to
> > split arguments like t
On Sun, 18 Apr 2004 10:02:14 -0500 (CDT), Bob Friesenhahn wrote:
> On Sun, 18 Apr 2004, Alexandre Duret-Lutz wrote:
> > This suggests that shell running this code does not split $list
> > and $subdir get the full list. Zsh would do that. Could you
> > compare the output of grep 'SHELL =' Makefile
On Tue, 17 Feb 2004, Vaclav Haisman wrote:
> That is afaik because teh checked out files have bad time stamps. configure's
> time stamp must be the younger than configure.in's, Makefile.in's younger than
> Makefile.am's etc.
CVS does not preserve time stamps. Freshly checked out files have the
c
That is afaik because teh checked out files have bad time stamps. configure's
time stamp must be the younger than configure.in's, Makefile.in's younger than
Makefile.am's etc.
WilX
On Tue, 17 Feb 2004, Nigel Kukard wrote:
> HI Guys,
>
> I've followed the documentation to make a gnu build syst
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> This is the third beta release of the next version of Automake (1.8).
Sorry I messed with the URLs. The release is 1.7f, not 1.7e.
Here are the corrected URL.
ftp://alpha.gnu.org/gnu/automake/automake-1.7f.tar.gz
ftp://alpha.gn
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Automakers:
Gary> I thought I would have a play with the single makefile support using
Gary> automake-1.7.6, but tripped over buggy support for LIBOBJS in subdirs.
Gary> This patch takes note of a AC_CONFIG_LIBOBJ_DIR declaration,
"L. D. Marks" <[EMAIL PROTECTED]> writes:
> 1) One of the systems has both X11R5 and X11R6 and it
> looks like AC_PATH_XTRA may be getting confused about
> which one to use. Does it seach by decreasing or increasing
> release?
I think it uses the first release it finds. The details are hairy tho
[Moving from autoconf@ to [EMAIL PROTECTED]
>>> "FAU" == Frank A Uepping <[EMAIL PROTECTED]> writes:
FAU> Hello,
FAU> I have the following directory layout:
FAU> src/
FAU> bar.c
FAU> src/common
FAU> foo.c
FAU> The program foobar should be build as follows (dependency):
FAU> foobar: b
At Tue, 01 Oct 2002 08:47:57 -0700,
Russ Allbery wrote:
> It's not too bad of a way to start, but it has a drawback that I've seen
> in probably the majority of Autoconf scripts out there, namely it creates
> a configure.in that checks for a bunch of things for which the source code
> has no worka
Nishio Futoshi <[EMAIL PROTECTED]> writes:
> My suggestion for beginers:
> Use autoscan in your source directory, then rename `configure.scan' to
> `configure.in'. Then edit `configure.in'. Your works are to modify
> `AC_INIT' arguments, comment out `AC_CONFIG_HEADERS', add
> AM_INIT_ATOMAKE([
Thank you for your reply, and I understand that.
I think that we can use `autoreconf' for bootstrap. We don't have to
invoke `aclocal', `automake', `autoconf', and `libtoolize' separately,
even if one uses Autotool for the first time with the package. Now we
can do that, `autoreconf --symlink
| At 26 Sep 2002 15:12:10 +0200,
| Akim Demaille wrote:
| > This is very bizarre! But I'm lost in your list of actions. Could
| > you send a small example of touch and cat that yields the problem? Or
| > a simple tarball in which one must run autoreconf? Thanks!
|
| I put tarbal http://www.d
| 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.
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. As each release
is r
>>> "Bob" == Bob Ham <[EMAIL PROTECTED]> writes:
[...]
Bob> Any idea when 1.7 will be released (roughly, obviously; I
Bob> mean, months? weeks? days?) I've got a build tree in a
Bob> cvs that uses cvs automake. It's waiting for 1.7 until
Bob> it's committed :)
CVS Automake needs Autocon
On Thursday 31 May 2001 7:47 pm, Dan Miner wrote:
> Hello,
Hello Dan,
> I've been reading the autoconf book and I find it quite useful; however,
> I've hit a wall and can't seem to wrap my head around it.
Glad you like the book.
> Quick layout
>
> proj/Makefile.am
> proj/configure.in
> proj/l
> I am wondering if the new preferred way of an empty AC_OUTPUT
> and use of AC_CONFIG_FILES in autoconf-2.49c is presently
> known to automake-1.4d or does automake still require the
> old way of doing AC_OUTPUT. Thanks.
CVS automake, and 1.4d too I believe, should support both the
old and the n
> "James" == jamesb <[EMAIL PROTECTED]> writes:
James> If automake is being orphaned in New Millenium, which I'm sure
James> I heard it was, I'd like to be the new maintainer.
The best way to do that is to start working on it now and submit
patches.
Tom
--- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 11, 2000 at 06:18:59AM -0700, Earnie Boyd wrote:
> : --- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> : > I've started using AC_CONFIG_AUX_DIR(aux) and stow away files into aux/.
> :
> : PORTABILITY Issue: aux should not be used as a direct
On Mon, Sep 11, 2000 at 06:18:59AM -0700, Earnie Boyd wrote:
: --- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
: > I've started using AC_CONFIG_AUX_DIR(aux) and stow away files into aux/.
:
: PORTABILITY Issue: aux should not be used as a directory, filename or filename
: part (i.e. aux, aux.foo or
On Mon, Sep 11, 2000 at 06:18:59AM -0700, Earnie Boyd wrote:
: --- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
: > I've started using AC_CONFIG_AUX_DIR(aux) and stow away files into aux/.
:
: PORTABILITY Issue: aux should not be used as a directory, filename or filename
: part (i.e. aux, aux.foo or
--- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> I've started using AC_CONFIG_AUX_DIR(aux) and stow away files into aux/.
PORTABILITY Issue: aux should not be used as a directory, filename or filename
part (i.e. aux, aux.foo or foo.aux) as it is treated as a device by DOS and
WIN32. If the directo
On Mon, Apr 03, 2000 at 08:17:02AM -0700, Bruce Korb wrote:
: Earnie Boyd wrote:
: > > How about mv'ing itself out of the way (to configure.bak or something
: > > similar)?
: > >
: >
: > Can't do that either. A mv is a cp && rm.
:
: 1. It is only for developers
: 2 How about putting at the e
--- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 03, 2000 at 07:46:08AM -0700, Earnie Boyd wrote:
> : --- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> : > How about mv'ing itself out of the way (to configure.bak or something
> : > similar)?
> :
> : Can't do that either. A mv is a cp && r
On Mon, Apr 03, 2000 at 07:46:08AM -0700, Earnie Boyd wrote:
: --- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
: > How about mv'ing itself out of the way (to configure.bak or something
: > similar)?
:
: Can't do that either. A mv is a cp && rm.
I thought it was a link() and an unlink(), but you're
Earnie Boyd wrote:
> > How about mv'ing itself out of the way (to configure.bak or something
> > similar)?
> >
>
> Can't do that either. A mv is a cp && rm.
1. It is only for developers
2 How about putting at the end:
( ( sleep 3 ; rm -f configure ; autoconf ) & )
exit 0
After 3 se
Earnie Boyd wrote:
>
> --- Bruce Korb <[EMAIL PROTECTED]> wrote:
> > I made an archive file named "configure" that contains
> > a shar archive of the generated files. It runs, recreating
> > the generated files, deletes itself and then runs autoconf.
>^^ NOT
--- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 03, 2000 at 06:57:33AM -0700, Earnie Boyd wrote:
> : --- Bruce Korb <[EMAIL PROTECTED]> wrote:
> : > I made an archive file named "configure" that contains
> : > a shar archive of the generated files. It runs, recreating
> : > the generat
On Mon, Apr 03, 2000 at 06:57:33AM -0700, Earnie Boyd wrote:
: --- Bruce Korb <[EMAIL PROTECTED]> wrote:
: > I made an archive file named "configure" that contains
: > a shar archive of the generated files. It runs, recreating
: > the generated files, deletes itself and then runs autoconf.
:
--- Bruce Korb <[EMAIL PROTECTED]> wrote:
-8<-
>
> I just installed a cute hack in the AutoGen CVS :-)
> I made an archive file named "configure" that contains
> a shar archive of the generated files. It runs, recreating
> the generated files, deletes itself and then runs autoconf.
Akim Demaille wrote:
> >> Is it working for you when you start from a clean just-checked-out
> >> repository?
>
> Alexandre> Nope. The first problem is that autoconf needs itself to
> Alexandre> bootstrap.
>
> Not really, the CVS repository contains the full tarball (with
> configure, Makefile.
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> CVS Autoconf sticks to Automake 1.4: that's why you find all
Akim> those problems. Use 1.4 instead, that's the easier way out.
Oops, now I remember you *should* use 1.4, otherwise, because we rely
on something which has changed bet
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Apr 2, 2000, Erez Zadok <[EMAIL PROTECTED]> wrote:
>> Have you tried to make dist in a a build dir that's not srcdir?
Alexandre> A long time ago, I installed a patch in autoconf to make it
Alexandre> work. I don't kn
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
>> > Update: I managed to solve that problem by rerunning automake on
>> the .am > files in the autoconf CVS repository.
>>
>> You must re-run aclocal before automake.
Erez> Thanks.
Erez> I still, however, seem to have a problem with make
On Apr 2, 2000, Erez Zadok <[EMAIL PROTECTED]> wrote:
> Have you tried to make dist in a a build dir that's not srcdir?
A long time ago, I installed a patch in autoconf to make it work. I
don't know if it has been broken again since then.
> Is it working for you when you start from a clean ju
In message <[EMAIL PROTECTED]>, Alexandre Oliva writes:
> On Apr 2, 2000, Erez Zadok <[EMAIL PROTECTED]> wrote:
>
> > Update: I managed to solve that problem by rerunning automake on the .am
> > files in the autoconf CVS repository.
>
> You must re-run aclocal before automake.
Thanks.
I still
On Apr 2, 2000, Erez Zadok <[EMAIL PROTECTED]> wrote:
> Update: I managed to solve that problem by rerunning automake on the .am
> files in the autoconf CVS repository.
You must re-run aclocal before automake.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus So
In message <[EMAIL PROTECTED]>, Erez Zadok writes:
> Autoconf expects automake to support a --build-dir option during "make
> dist". Automake doesn't support that option. I have the most recent CVS'ed
> versions. This has been not working for some time now. Will this simple
> problem be fixed
89 matches
Mail list logo
