You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Bojan Smojver <bo...@rexursive.com> on 2012/02/07 00:43:41 UTC
Version of autoconf for releases?
What version of autoconf should I have for rolling releases of APR? I'm
getting quite a few warnings and errors with the default on F-16, so I'm
guessing I have to go a bit back, but what to exactly escapes me now...
--
Bojan
Re: Version of autoconf for releases?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Feb 7, 2012 at 5:03 PM, Bojan Smojver <bo...@rexursive.com> wrote:
> On Tue, 2012-02-07 at 17:00 -0500, Jeff Trawick wrote:
>> Using the slightly patched tool(s) from Fedora seems like a pain for
>> others to reproduce exactly, whereas anyone can install autotools of
>> arbitrary versions on arbitrary non-Windows machines in just a few
>> minutes
>
> So, you want me to keep the vanilla libtool 2.2.4 (which is giving
> warnings) as well, or should I shoot for the current release (2.4.2),
> which will have those fixed?
I didn't intend to mix those separate issues ;)
Vanilla is better than vendor-patched so that others can quickly
reproduce the same results (IOW roll the next version without
introducing mysterious diffs in the generated files).
If 2.4.2 fixes issues when it is combined with 2.68, go for that.
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2012-02-07 at 17:00 -0500, Jeff Trawick wrote:
> Using the slightly patched tool(s) from Fedora seems like a pain for
> others to reproduce exactly, whereas anyone can install autotools of
> arbitrary versions on arbitrary non-Windows machines in just a few
> minutes
So, you want me to keep the vanilla libtool 2.2.4 (which is giving
warnings) as well, or should I shoot for the current release (2.4.2),
which will have those fixed?
--
Bojan
Re: Version of autoconf for releases?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Feb 7, 2012 at 4:54 PM, Bojan Smojver <bo...@rexursive.com> wrote:
> On Wed, 2012-02-08 at 08:02 +1100, Bojan Smojver wrote:
>> Libtool is slightly ahead: 2.4 v 2.2.4, but this is not where the
>> warnings are coming from (mostly).
>
> Actually, that is not correct. If I use 2.2.4 instead of built-in 2.4, I
> do get warnings and they do come from the files contributed by this
> version of libtool. Pretty much the same stuff as what Rainer fixed in
> APR - missing AC_LANG_SOURCE.
>
> So, given that vanilla autoconf and the one from F-16 are pretty much
> the same thing and given that libtool 2.2.4 is giving warnings (i.e. is
> obviously more obsolete than 2.4, when used with autoconf 2.68), I think
> I should just roll the 1.4.6 release with the tools I have in F-16. If
> that turns out bogus, I will release again. Version numbers are cheap.
>
> If you disagree with this assessment, let me know.
Using the slightly patched tool(s) from Fedora seems like a pain for
others to reproduce exactly, whereas anyone can install autotools of
arbitrary versions on arbitrary non-Windows machines in just a few
minutes.
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2012-02-08 at 08:02 +1100, Bojan Smojver wrote:
> Libtool is slightly ahead: 2.4 v 2.2.4, but this is not where the
> warnings are coming from (mostly).
Actually, that is not correct. If I use 2.2.4 instead of built-in 2.4, I
do get warnings and they do come from the files contributed by this
version of libtool. Pretty much the same stuff as what Rainer fixed in
APR - missing AC_LANG_SOURCE.
So, given that vanilla autoconf and the one from F-16 are pretty much
the same thing and given that libtool 2.2.4 is giving warnings (i.e. is
obviously more obsolete than 2.4, when used with autoconf 2.68), I think
I should just roll the 1.4.6 release with the tools I have in F-16. If
that turns out bogus, I will release again. Version numbers are cheap.
If you disagree with this assessment, let me know.
--
Bojan
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2012-02-07 at 07:18 -0500, Jeff Trawick wrote:
> Please use clean builds of the the autoconf and libtool versions that
> Graham used. I hate seeing the autotools versions jumping around as
> different people handle T&R.
Just for the record, autoconf in F-16 is the same version as vanilla
autoconf used by Graham: 2.68, plus one patch:
http://pkgs.fedoraproject.org/gitweb/?p=autoconf.git;a=blob_plain;f=autoconf-2.68-selfcheckfailure.patch;hb=f16
Libtool is slightly ahead: 2.4 v 2.2.4, but this is not where the
warnings are coming from (mostly).
--
Bojan
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2012-02-07 at 16:42 +0200, Graham Leggett wrote:
> Has anyone gone through the warnings to determine if the warnings
> should cause concern?
AFAICT, they are all benign warnings like this
AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body:
http://www.flameeyes.eu/autotools-mythbuster/forwardporting/autoconf.html
Coming from APR_TRY_COMPILE_NO_WARNING (which appears to be correct).
There is also a benign:
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
--
Bojan
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2012-02-07 at 22:09 +0100, Rainer Jung wrote:
> There is no analogous change for apr-util, but as far as I remember
> those warnings did not exist for apr-util. Bojan please correct me if
> your experience is different.
I haven't tried apr-util spin yet, to be honest. We'll cross that bridge
when we get to it.
PS. Thanks for actually fixing this. It didn't occur to me to read the
log at all. :-(
--
Bojan
Re: Version of autoconf for releases?
Posted by Rainer Jung <ra...@kippdata.de>.
On 07.02.2012 15:42, Graham Leggett wrote:
> On 07 Feb 2012, at 3:45 PM, Jeff Trawick wrote:
>
>> I agree 100%. And hopefully we also agree that the order should be
>>
>> 1. make the fixes to our code
>> 2. start using autoconf v2.68
>>
>> Also, that's not a showstopper for a release, so an RM should use the
>> known-compatible version of autoconf for new releases until any
>> glitches are resolved.
>
> Warnings are exactly that - warnings. If all we're doing is using a version of autoconf that complains less, but otherwise does nothing different to the current version, we're not achieving anything by doing that.
>
> Has anyone gone through the warnings to determine if the warnings should cause concern?
As far as I understood Bojan this is no longer an issue. If he tries to
prepare 1.4.x head for release there are no warnings and that is the
code we are going to release.
In case we wonder why there are no warnings for head but there are
warnings for 1.4.5: see CHANGES:
*) Silence autoconf 2.68 warnings. [Rainer Jung]
in the 1.4.6 block.
The change was
http://svn.apache.org/viewvc?view=revision&revision=1125474, svn log was
Silence autoconf 2.68 warnings.
Add AC_LANG_SOURCE to AC_COMPILE_IFELSE
in apr_common.m4.
Backport of r1125472 from trunk
resp. r1125473 from 1.5.x.
There is no analogous change for apr-util, but as far as I remember
those warnings did not exist for apr-util. Bojan please correct me if
your experience is different.
Regards and happy RMing
Rainer
Re: Version of autoconf for releases?
Posted by Graham Leggett <mi...@sharp.fm>.
On 07 Feb 2012, at 3:45 PM, Jeff Trawick wrote:
> I agree 100%. And hopefully we also agree that the order should be
>
> 1. make the fixes to our code
> 2. start using autoconf v2.68
>
> Also, that's not a showstopper for a release, so an RM should use the
> known-compatible version of autoconf for new releases until any
> glitches are resolved.
Warnings are exactly that - warnings. If all we're doing is using a version of autoconf that complains less, but otherwise does nothing different to the current version, we're not achieving anything by doing that.
Has anyone gone through the warnings to determine if the warnings should cause concern?
Regards,
Graham
--
Re: Version of autoconf for releases?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Feb 7, 2012 at 8:26 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 07 Feb 2012, at 3:02 PM, Jeff Trawick wrote:
>
>> Then the use of autoconf 2.68 was premature. Move back to autoconf
>> 2.64, which should be fine. When it works cleanly with 2.68 we can
>> move forward again.
>
> According to http://ftp.gnu.org/gnu/autoconf/, autoconf v2.68 was released in September 2010, which is now 15 months old and counting. The autoconf project has not made a release since, so I conclude from that the people who make autoconf are happy with it's operation.
>
> This means if we are seeing warnings, it's probably our fault, and is something we should look at and fix in our build environment. Warnings today are tomorrows errors, so we're going to have to fix them eventually anyway.
I agree 100%. And hopefully we also agree that the order should be
1. make the fixes to our code
2. start using autoconf v2.68
Also, that's not a showstopper for a release, so an RM should use the
known-compatible version of autoconf for new releases until any
glitches are resolved.
Re: Version of autoconf for releases?
Posted by Graham Leggett <mi...@sharp.fm>.
On 07 Feb 2012, at 3:02 PM, Jeff Trawick wrote:
> Then the use of autoconf 2.68 was premature. Move back to autoconf
> 2.64, which should be fine. When it works cleanly with 2.68 we can
> move forward again.
According to http://ftp.gnu.org/gnu/autoconf/, autoconf v2.68 was released in September 2010, which is now 15 months old and counting. The autoconf project has not made a release since, so I conclude from that the people who make autoconf are happy with it's operation.
This means if we are seeing warnings, it's probably our fault, and is something we should look at and fix in our build environment. Warnings today are tomorrows errors, so we're going to have to fix them eventually anyway.
Regards,
Graham
--
Re: Version of autoconf for releases?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Feb 7, 2012 at 7:48 AM, Bojan Smojver <bo...@rexursive.com> wrote:
> ------- Original message -------
>>
>> From: Jeff Trawick
>
>
>> Please use clean builds of the the autoconf and libtool versions that
>> Graham used. I hate seeing the autotools versions jumping around as
>> different people handle T&R.
>
>
> These "clean" tools don't look so clean on my box, so I think I'll hold off
> on T&R until I figure this out properly.
Then the use of autoconf 2.68 was premature. Move back to autoconf
2.64, which should be fine. When it works cleanly with 2.68 we can
move forward again.
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
------- Original message -------
> From: Jeff Trawick
> Please use clean builds of the the autoconf and libtool versions that
> Graham used. I hate seeing the autotools versions jumping around as
> different people handle T&R.
These "clean" tools don't look so clean on my box, so I think I'll hold off
on T&R until I figure this out properly.
--
Bojan
Re: Version of autoconf for releases?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Feb 6, 2012 at 9:55 PM, Bojan Smojver <bo...@rexursive.com> wrote:
> On Tue, 2012-02-07 at 11:31 +1100, Bojan Smojver wrote:
>> This is what I get when I run the release.sh script against 1.4.5 tag
>
> Interestingly, if I rework release.sh to use branches instead of tags
> and give it 1.4.x as an argument, everything turns out clean with F-16
> defaults:
> ---------------
> Eliminating unwanted files (e.g. .cvsignore) and generating initial
> files via buildconf ...
>
> buildconf: checking installation...
> buildconf: python version 2.7.2 (ok)
> buildconf: autoconf version 2.68 (ok)
> buildconf: libtool version 2.4 (ok)
Please use clean builds of the the autoconf and libtool versions that
Graham used. I hate seeing the autotools versions jumping around as
different people handle T&R.
> buildconf: copying libtool helper files using /usr/bin/libtoolize
> buildconf: creating include/arch/unix/apr_private.h.in ...
> buildconf: creating configure ...
> buildconf: generating 'make' outputs ...
> buildconf: rebuilding rpm spec file
> ---------------
>
> Build from the tarball works fine. So, maybe that's the ticket after
> all.
>
> PS. 0.9.x is broken, but not too worried about that.
>
> --
> Bojan
>
--
Born in Roswell... married an alien...
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2012-02-07 at 11:31 +1100, Bojan Smojver wrote:
> This is what I get when I run the release.sh script against 1.4.5 tag
Interestingly, if I rework release.sh to use branches instead of tags
and give it 1.4.x as an argument, everything turns out clean with F-16
defaults:
---------------
Eliminating unwanted files (e.g. .cvsignore) and generating initial
files via buildconf ...
buildconf: checking installation...
buildconf: python version 2.7.2 (ok)
buildconf: autoconf version 2.68 (ok)
buildconf: libtool version 2.4 (ok)
buildconf: copying libtool helper files using /usr/bin/libtoolize
buildconf: creating include/arch/unix/apr_private.h.in ...
buildconf: creating configure ...
buildconf: generating 'make' outputs ...
buildconf: rebuilding rpm spec file
---------------
Build from the tarball works fine. So, maybe that's the ticket after
all.
PS. 0.9.x is broken, but not too worried about that.
--
Bojan
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2012-02-06 at 19:14 -0500, Jeff Trawick wrote:
> Can you post?
This is what I get when I run the release.sh script against 1.4.5 tag:
------------------
buildconf: checking installation...
buildconf: python version 2.7.2 (ok)
buildconf: autoconf version 2.68 (ok)
buildconf: libtool version 2.4 (ok)
buildconf: copying libtool helper files using /usr/bin/libtoolize
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'.
libtoolize: copying file `build/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `build'.
libtoolize: copying file `build/libtool.m4'
libtoolize: copying file `build/ltoptions.m4'
libtoolize: copying file `build/ltsugar.m4'
libtoolize: copying file `build/ltversion.m4'
libtoolize: copying file `build/lt~obsolete.m4'
libtoolize: Consider adding `-I build' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
buildconf: creating include/arch/unix/apr_private.h.in ...
configure.in:2054: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
build/apr_common.m4:491: APR_TRY_COMPILE_NO_WARNING is expanded from...
configure.in:2054: the top level
configure.in:2569: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
build/apr_common.m4:491: APR_TRY_COMPILE_NO_WARNING is expanded from...
build/apr_network.m4:223: APR_CHECK_GETHOSTBYNAME_R_STYLE is expanded from...
configure.in:2569: the top level
configure.in:2574: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
build/apr_common.m4:491: APR_TRY_COMPILE_NO_WARNING is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
build/apr_network.m4:291: APR_CHECK_GETSERVBYNAME_R_STYLE is expanded from...
configure.in:2574: the top level
buildconf: creating configure ...
configure.in:2054: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
build/apr_common.m4:491: APR_TRY_COMPILE_NO_WARNING is expanded from...
configure.in:2054: the top level
configure.in:2569: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
build/apr_common.m4:491: APR_TRY_COMPILE_NO_WARNING is expanded from...
build/apr_network.m4:223: APR_CHECK_GETHOSTBYNAME_R_STYLE is expanded from...
configure.in:2569: the top level
configure.in:2574: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
build/apr_common.m4:491: APR_TRY_COMPILE_NO_WARNING is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
build/apr_network.m4:291: APR_CHECK_GETSERVBYNAME_R_STYLE is expanded from...
configure.in:2574: the top level
buildconf: generating 'make' outputs ...
buildconf: rebuilding rpm spec file
------------------
Which makes me think that I'll bump into similar with 1.4.6.
The situation with 0.9.20 is worse. It actually fails. But, I'm not too
fussed about that - I don't use it at all. Selfish, I know :-).
--
Bojan
Re: Version of autoconf for releases?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Feb 6, 2012 at 7:09 PM, Bojan Smojver <bo...@rexursive.com> wrote:
> On Mon, 2012-02-06 at 19:06 -0500, Jeff Trawick wrote:
>> Use whatever was used for apr-util 1.4.1 in order to avoid surprises.
>
> OK.
>
>> I think that is autoconf 2.68 (says configure)
>
> Yeah, that's what I have on F-16, which gives me plenty of warnings.
Can you post?
>
>> and libtool 2.2.4 (says xml/expat/conftools/ltmain.sh).
>
> That's different. Have 2.4 on F-16.
>
> OK, I guess I'll have to install some vanilla stuff.
>
> --
> Bojan
>
--
Born in Roswell... married an alien...
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2012-02-06 at 19:06 -0500, Jeff Trawick wrote:
> Use whatever was used for apr-util 1.4.1 in order to avoid surprises.
OK.
> I think that is autoconf 2.68 (says configure)
Yeah, that's what I have on F-16, which gives me plenty of warnings.
> and libtool 2.2.4 (says xml/expat/conftools/ltmain.sh).
That's different. Have 2.4 on F-16.
OK, I guess I'll have to install some vanilla stuff.
--
Bojan
Re: Version of autoconf for releases?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Feb 6, 2012 at 6:43 PM, Bojan Smojver <bo...@rexursive.com> wrote:
> What version of autoconf should I have for rolling releases of APR? I'm
> getting quite a few warnings and errors with the default on F-16, so I'm
> guessing I have to go a bit back, but what to exactly escapes me now...
Use whatever was used for apr-util 1.4.1 in order to avoid surprises.
I think that is autoconf 2.68 (says configure) and libtool 2.2.4 (says
xml/expat/conftools/ltmain.sh).
Re: Version of autoconf for releases?
Posted by Bojan Smojver <bo...@rexursive.com>.
On Tue, 2012-02-07 at 00:43 +0000, Graham Leggett wrote:
> The versions I used to roll apr-util v1.4.1 were vanilla builds, built
> from pristine source, as opposed to the packages shipped with FC-17 or
> MacOSX.
Tried with that on my F-16 machine and got similar warnings. Also got a
tarball that didn't work. I think I'll need to dig a bit more...
--
Bojan
Re: Version of autoconf for releases?
Posted by Graham Leggett <mi...@sharp.fm>.
On 6 Feb 2012, at 23:43, Bojan Smojver <bo...@rexursive.com> wrote:
> What version of autoconf should I have for rolling releases of APR? I'm
> getting quite a few warnings and errors with the default on F-16, so I'm
> guessing I have to go a bit back, but what to exactly escapes me now...
The versions I used to roll apr-util v1.4.1 were vanilla builds, built from pristine source, as opposed to the packages shipped with FC-17 or MacOSX.
Regards,
Graham
--