On 14/03/2022 22:15, Adam Dinwoodie wrote:
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit more future-proof by parsing
out the actual
On Mon, Mar 14, 2022 at 07:05:20PM +, Jon Turney wrote:
> On 13/03/2022 20:44, Adam Dinwoodie wrote:
> > configure="${confdir}/configure"
> > confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
> > + confver_maj=${confver%%.*
On 13/03/2022 20:44, Adam Dinwoodie wrote:
configure="${confdir}/configure"
confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
+ confver_maj=${confver%%.*}
+ confver_min=${confver##*.}
+ if [ $confver_maj -ne 2 ]
+ then
+
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit more future-proof by parsing
out the actual
2 -a $confver_min -ge 60 ] || [ $confver_maj -ge
> > 3 ]
>
> Great. Thanks.
>
> I think it would be acceptable to error on autoconf >=3.0, rather than
> assuming it's going to be autoconf 2.6+ compatible.
No problem, I'll respin now. I'd thought about doing exactly that, but
the c
On 11/03/2022 22:40, Adam Dinwoodie wrote:
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit more future-proof by parsing
out the actual
On 1/2/2022 12:22 PM, Marco Atzeri wrote:
On 05.12.2021 10:34, Achim Gratz wrote:
In order for cygport to work correctly when autoconf 2.71 is requested,
please pull the first commit (b25cb3faa) on my to-upstream branch into
upstream and release a new version. I'd appreciate if the full
On 05.12.2021 10:34, Achim Gratz wrote:
In order for cygport to work correctly when autoconf 2.71 is requested,
please pull the first commit (b25cb3faa) on my to-upstream branch into
upstream and release a new version. I'd appreciate if the full branch
would be pulled, these are all used by me
On 2021-12-07 13:16, Ken Brown wrote:
[Redirected from the cygwin list,
https://cygwin.com/pipermail/cygwin/2021-December/250149.html]
On 12/7/2021 3:08 PM, Ken Brown wrote:
On 12/5/2021 3:50 AM, Achim Gratz wrote:
Autoconf upstream has stated that the 2.7x releases are not fully
backwards
[Redirected from the cygwin list,
https://cygwin.com/pipermail/cygwin/2021-December/250149.html]
On 12/7/2021 3:08 PM, Ken Brown wrote:
On 12/5/2021 3:50 AM, Achim Gratz wrote:
Autoconf upstream has stated that the 2.7x releases are not fully
backwards compatible. Cygwin therefore chose
In order for cygport to work correctly when autoconf 2.71 is requested,
please pull the first commit (b25cb3faa) on my to-upstream branch into
upstream and release a new version. I'd appreciate if the full branch
would be pulled, these are all used by me for quite some time already.
e33b0b7f1
Achim Gratz writes:
> In light of the fact that 2.71 again is not backwards compatible, that
> patch needs to be somewhat more extensive and include different
> WANT_AUTOCONF settings.
Something like this, which keeps the default autoconf version at 2.69
for the moment (and is untested
Ken Brown via Cygwin-apps writes:
> On 12/2/2021 5:15 AM, Jan Nijtmans via Cygwin-apps wrote:
>> Somewhere in cygport, a check is done for the autoconf version, please
>> change this check to allow autoconf 2.71 (as well as 2.59 and 2.69).
>> Then I can put back the
On 12/2/2021 8:32 AM, Corinna Vinschen via Cygwin-apps wrote:
On Dec 2 14:18, ASSI wrote:
As I said, I haven't looked at it in any detail, but it seems that
autoconf is already multi-version, so I guess it would be possible to
introduce an autoconf2.7 package in addition to the existing two
On Dec 2 14:18, ASSI wrote:
> Jan Nijtmans via Cygwin-apps writes:
> > My 2c : Cygwin should - at least - allow people to install autoconf-2.71
> > and - as long as the packages are prepared for it - things shouldn't break.
>
> As I said, I haven't looked at it in any
On 12/2/2021 5:15 AM, Jan Nijtmans via Cygwin-apps wrote:
Somewhere in cygport, a check is done for the autoconf version, please
change this check to allow autoconf 2.71 (as well as 2.59 and 2.69).
Then I can put back the "cygautoreconf" line in tcl.cygport.
You can do this loc
Jan Nijtmans via Cygwin-apps writes:
> My 2c : Cygwin should - at least - allow people to install autoconf-2.71
> and - as long as the packages are prepared for it - things shouldn't break.
As I said, I haven't looked at it in any detail, but it seems that
autoconf is already multi-version
Op do 2 dec. 2021 om 11:41 schreef Corinna Vinschen via Cygwin-apps:
> Nope, I didn't. Make that:
>
> On Dec 2 08:23, ASSI wrote:
Indeed, sorry!. I stripped a little bit too much from the message ...
Regards,
Jan Nijtmans
ntial rolling release distros. As long as these guys don't use
> > > the newer version it seems unlikely that we would actually need it, plus
> > > I don't see us spending time and effort debugging things that aren't
> > > even Cygwin specific.
>
> My 2c : Cygwin sho
ally need it, plus
> > I don't see us spending time and effort debugging things that aren't
> > even Cygwin specific.
My 2c : Cygwin should - at least - allow people to install autoconf-2.71
and - as long as the packages are prepared for it - things shouldn't break.
If I install autoconf-
ing things that aren't
> even Cygwin specific.
>
> > After that version released in January, I've only had to patch one
> > package so far, which specified it in August, and they later reduced
> > it after discussion with distro package maintainers:
> >
> > $
ary, I've only had to patch one
> package so far, which specified it in August, and they later reduced
> it after discussion with distro package maintainers:
>
> $ grep 'AC_PREREQ(\[2\.[0-9]\+\])' */*.patch
> bison/bison-3.7.90-revert-autoconf-upgrade.patch:-AC_PREREQ([2.71])
>
On 2021-12-01 12:56, Achim Gratz wrote:
Marco Atzeri via Cygwin-apps writes:
anyone working or planning to take over the Autoconf ?
I haven't, but looking at the packages I picked up maybe I should.
The 2.71 version seems becoming popular in some package source code.
How likely
Marco Atzeri via Cygwin-apps writes:
> anyone working or planning to take over the Autoconf ?
I haven't, but looking at the packages I picked up maybe I should.
> The 2.71 version seems becoming popular in some package source code.
How likely is it that they actually rely on that v
Hi Guys,
anyone working or planning to take over the Autoconf ?
The 2.71 version seems becoming popular in some package source code.
Regards
Marco
On 2021-10-02 10:35, Brian Inglis wrote:
On 2021-10-02 08:13, Ken Brown via Cygwin-apps wrote:
On 10/2/2021 1:48 AM, Brian Inglis wrote:
On 2021-10-01 22:15, Achim Gratz wrote:
Brian Inglis writes:
As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that
would be the more
On 2021-10-02 08:13, Ken Brown via Cygwin-apps wrote:
On 10/2/2021 1:48 AM, Brian Inglis wrote:
On 2021-10-01 22:15, Achim Gratz wrote:
Brian Inglis writes:
As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that
would be the more appropriate place for an autoconf-archive
On 10/2/2021 1:48 AM, Brian Inglis wrote:
On 2021-10-01 22:15, Achim Gratz wrote:
Brian Inglis writes:
As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that
would be the more appropriate place for an autoconf-archive
requirement, otherwise cygport would have to require
On 2021-10-01 22:15, Achim Gratz wrote:
Brian Inglis writes:
As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that
would be the more appropriate place for an autoconf-archive
requirement, otherwise cygport would have to require it, which is not
so obvious.
No. If a build
Brian Inglis writes:
> As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that
> would be the more appropriate place for an autoconf-archive
> requirement, otherwise cygport would have to require it, which is not
> so obvious.
No. If a build needs autoconf-archive
macro: AX_CODE_COVERAGE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation."
CI scallywag setup does not install nor does cygport nor autoconf
require autoconf-archive so packages have to include in BUILD_REQUIRES.
As autoconf requires: autoconf2.1 a
If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation."
>
> CI scallywag setup does not install nor does cygport nor autoconf
> require autoconf-archive so packages have to include in BUILD_REQUIRES.
>
> As autoconf requ
Hi folks,
Autotools needs m4 macros in autoreconf-archive to config for gcov and
other dependencies or build fails with e.g.
"configure.ac:33: error: possibly undefined macro: AX_CODE_COVERAGE
If this token and others are legitimate, please use m4_pattern_allow.
See the Aut
On 7/8/2013 9:30 PM, Charles Wilson wrote:
I've updated the following 64bit packages:
autoconf-13-1 (wrapper)
autoconf2.1-2.13-12
autoconf2.5-2.69-2
See the 32bit announcement(s) for details.
Chuck,
I think you forgot to run the GEN-sware script after uploading the 64bit
packages
I've updated the following 64bit packages:
autoconf-13-1 (wrapper)
autoconf2.1-2.13-12
autoconf2.5-2.69-2
See the 32bit announcement(s) for details.
--
Chuck
On 2013-05-14 15:13, marco atzeri wrote:
Il 5/14/2013 9:05 PM, Corinna Vinschen ha scritto:
I fear you might not like my answer: The problem here is NOT that the
linking works, the problem is that, if the configure test is used to
find out if we're running on Windows or not, it's simply not
On May 14 20:19, Charles Wilson wrote:
On 5/14/2013 3:05 PM, Corinna Vinschen wrote:
I fear you might not like my answer: The problem here is NOT that the
linking works, the problem is that, if the configure test is used to
find out if we're running on Windows or not, it's simply not feasible
Il 5/14/2013 9:05 PM, Corinna Vinschen ha scritto:
On May 14 20:30, marco atzeri wrote:
I fear you might not like my answer: The problem here is NOT that the
linking works, the problem is that, if the configure test is used to
find out if we're running on Windows or not, it's simply not
On 5/14/2013 3:05 PM, Corinna Vinschen wrote:
I fear you might not like my answer: The problem here is NOT that the
linking works, the problem is that, if the configure test is used to
find out if we're running on Windows or not, it's simply not feasible
anymore when taking x86_64 Cygwin into
Hi gang, and Chuck in particular,
Ralf Wildenhues wrote:
Hello everyone,
I will reply to this message with a number of patches that contain the
heart of the switch to newer autotools.
Ralf's posting patches to get GCC and /src switched over to new autotools.
Do you have some spare
Eric Blake e...@byu.net writes:
According to Christopher Faylor on 1/6/2009 11:00 PM:
On Wed, Jan 07, 2009 at 12:37:37AM -0500, Charles Wilson wrote:
Charles Wilson wrote:
This should make it easier for Dave, and those who want to help him, to
develop gcc and binutils -- avoiding things
Den 2009-01-08 18:06, skrev Jari Aalto:
Eric Blake e...@byu.net writes:
According to Christopher Faylor on 1/6/2009 11:00 PM:
On Wed, Jan 07, 2009 at 12:37:37AM -0500, Charles Wilson wrote:
Charles Wilson wrote:
This should make it easier for Dave, and those who want to help him, to
On Thu, Jan 08, 2009 at 07:11:29PM +0100, Peter Rosin wrote:
Den 2009-01-08 18:06, skrev Jari Aalto:
Eric Blake e...@byu.net writes:
According to Christopher Faylor on 1/6/2009 11:00 PM:
On Wed, Jan 07, 2009 at 12:37:37AM -0500, Charles Wilson wrote:
Charles Wilson wrote:
This should make
Christopher Faylor wrote:
On Wed, Jan 07, 2009 at 12:37:37AM -0500, Charles Wilson wrote:
Charles Wilson wrote:
This should make it easier for Dave, and those who want to help him, to
develop gcc and binutils -- avoiding things like this:
http://www.cygwin.com/ml/cygwin/2008-12/msg00201.html
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 1/6/2009 11:00 PM:
On Wed, Jan 07, 2009 at 12:37:37AM -0500, Charles Wilson wrote:
Charles Wilson wrote:
This should make it easier for Dave, and those who want to help him, to
develop gcc and binutils --
On Wed, Jan 07, 2009 at 09:44:39AM -0500, Charles Wilson wrote:
But I didn't. So if you (cgf) would like, I'll pull the gcc-tools-*
packages and wait for 3 (2 more now, counting Eric's) more votes. No big
deal.
I'm not going to pull the package but I couldn't let a confusing email
sit in the
Now, let's try that again, only without the comedy Reply-To: header this time!
Charles Wilson wrote:
http://cygwin.cwilson.fastmail.fm/ITP/gcc-tools-autoconf-2.59-2-src.tar.bz2
http://cygwin.cwilson.fastmail.fm/ITP/gcc-tools-autoconf-2.59-2.tar.bz2
http://cygwin.cwilson.fastmail.fm/ITP/gcc
Christopher Faylor wrote:
I've renamed the autoconf subdirectory from gcc-tools to
gcc-tools-autoconf. And, I've renamed the automake subdirectory from
gcc-tools to gcc-tools-automake.
Sorry about that. genini was perfectly happy with the way I had it, but
upset is more picky. I fixed
On Wed, Jan 07, 2009 at 12:37:37AM -0500, Charles Wilson wrote:
Charles Wilson wrote:
This should make it easier for Dave, and those who want to help him, to
develop gcc and binutils -- avoiding things like this:
http://www.cygwin.com/ml/cygwin/2008-12/msg00201.html
Well, given Dave's positive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
Special versions of pristine (that is, no cygwin-special patches) of
autoconf-2.59 and automake-1.9.6 as required by gcc, installed into
/opt/gcc-tools/{bin|lib|share}.
There's another, *much* simpler way to do
Yaakov (Cygwin/X) wrote:
Charles Wilson wrote:
Special versions of pristine (that is, no cygwin-special patches) of
autoconf-2.59 and automake-1.9.6 as required by gcc, installed into
/opt/gcc-tools/{bin|lib|share}.
There's another, *much* simpler way to do this; .cygport attached
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Charles Wilson wrote:
Yes, because gcc requires the use of an unmodified automake. Our
existing 1.9.6 package is modified [*] -- and you can't have two
versions of the same minor automake release installed at the same time
in the same prefix.
Yaakov (Cygwin/X) wrote:
Charles Wilson wrote:
In what way does gcc require a vanilla automake? Below you say that
the only difference is some libobj fixes. To me that means that gcc
will build, but the patches won't be quite right (meaning that gcc keeps
Makefile.in in CVS?). That's not
-Original Message-
From: Paul Eggert
[mailto:[EMAIL PROTECTED] Behalf Of
Paul Eggert
Sent: Monday, June 26, 2006 7:58 PM
To: GNU Info Address (ML?)
Cc: various GNU mailing lists
Subject: Autoconf 2.60 released
We're happy to announce the release of Autoconf 2.60.
Please grab it from one
I am sorry for the raw email address.
-Original Message-
From: cygwin-apps
Sent: Wednesday, June 28, 2006 11:37 PM
To: Cygwin-Apps Mailing List; Cygwin Mailing List
Subject: FW: Autoconf 2.60 released
-Original Message-
From: Paul Eggert
Paul Eggert
Sent: Monday, June 26, 2006 7
RE: http://cygwin.com/ml/cygwin-patches/2006-q2/msg00051.html
I am not subscribed to cygwin-patches so I'm posting here. Forgive me
if I've transgressed boundares, but I've always considered mingw as a
cygwin-dependent app.
Applying the above patch, running aclocal and then autoconf-2.5x
the above patch, running aclocal and then autoconf-2.5x, then
./configure ---host=mingw32 --target=mingw32 works for mingw and w32api
subdirs from a cygwin bash shell.
I haven't tried with msys tools since I don't have them.
Didn't you notice some problems with AC_CONFIG_AUX_DIR being set
I'm tyring to port some webdav stuff, but it needs new autoconf. The
newest seems to be 2.57. Could we get an update or is there problems
with new autoconf versions?
Jari
--
http://tiny-tools.sourceforge.net/
Swatch @time http://www.ryanthiessen.com/swatch/resources.htm
Convert @time http
On Fri, 4 Jul 2003, Jari Aalto+list.cygwin-apps wrote:
I'm tyring to port some webdav stuff, but it needs new autoconf. The
newest seems to be 2.57. Could we get an update or is there problems
with new autoconf versions?
Install the 'autoconf-devel' package and put `/usr/autotool/devel/bin
But, development and maintenance of 2.13 is dead for Autoconf proper. There have been
three
or four releases since then. If the developers who use Cygwin want to continue to
support
2.13 that's a different matter and those developers, someone like Dan Kegel, can
create the
patch
I would certainly agree, except that the gcc developers
tried and failed to update to 2.53; it's really involved to
update gcc's autoconf.
The only project that I think should be using my patch is the
gcc project, and only until they update to autoconf 2.53.
Everyone else should move
Dan Kegel wrote:
The only project that I think should be using my patch is the
gcc project, and only until they update to autoconf 2.53.
Everyone else should move to autoconf 2.53 asap.
I agree completely, in fact, the entire sources.redhat.com cvs tree
needs to move on up to autoconf-2.53
I suggest that this issue be dealt with within the Cygwin distribution of
autoconf-2.13.
Earnie.
Dan Kegel wrote:
[repost -- mail system problems]
Building cross gcc's on cygwin fails because autoconf 2.13's AC_TRY_COMPILER
test assumes that it's ok to try to run possibly cross-compiled
of configure scripts is to be portable, so
it makes a fair bit of sense for gcc to ship with configure scripts
that are portable even to systems like cygwin.
- Dan
Earnie Boyd wrote:
I suggest that this issue be dealt with within the Cygwin distribution of
autoconf-2.13.
Earnie.
Dan Kegel wrote
Chuck,
The wrapper scripts for autoconf and autoheader use temporary files
that they (are supposed to) remove on exit (using trap 0). But I tend
to find *lots* of these directories in /tmp (e.g. /tmp/acX and
/tmp/ahX). Just running autoconf or autoheader with no arguments
creates
Charles Wilson [EMAIL PROTECTED] wrote:
Yeah, I've noticed that too. Perhaps I outsmarted myself:
the wrapper script never actually exits
-- it *execs* the real autoconf/make/whatever.
So perhaps the trap doesn't get triggered when you exec.
Yep: that's what it is. I constructed various
not having an
Autoconf bias here) which has unbalanced `)', M4 will think your
case's `)' are macro invocation closers.
| Again, this is true for ac-2.53, ac-2.53a, and ac-2.52.
Sure! A broken configure.in is broken independently of the Autoconf
version :)
| --- cvs-1.11.2-orig/configure
Oops. Sorry for the crosspost. This actually belongs on the autoconf
mailing list. (Darned auto-complete put the wrong address in for Corinna).
But, since we're here:
It looks like my recent reports about problems with autoconf were
incorrect. Akim has nicely pointed out that PIBKAC
Corinna Vinschen wrote:
I read them. It doesn't sound as if marking them current would
break anything (which is, OTOH, another set of famous last words)
so, go ahead.
Done.
--Chuck
On 3/25, I uploaded new versions of autoconf-devel and automake-devel,
but I didn't mark them current because Corinna was on vacation.
Corinna, any objections to removing the 'test' designation from
autoconf-devel-2.53-1 and automake-1.6-1 ? (Be sure to read the
previously posted
72 matches
Mail list logo
