Re: Version of autoconf for releases?
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 TR. 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?
--- 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 TR. These clean tools don't look so clean on my box, so I think I'll hold off on TR until I figure this out properly. -- Bojan
Re: Version of autoconf for releases?
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 TR. These clean tools don't look so clean on my box, so I think I'll hold off on TR 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?
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 -- smime.p7s Description: S/MIME cryptographic signature
Re: Version of autoconf for releases?
On Tue, Feb 7, 2012 at 8:26 AM, Graham Leggett minf...@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?
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 -- smime.p7s Description: S/MIME cryptographic signature
Re: Version of autoconf for releases?
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?
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 TR. 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?
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=revisionrevision=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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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 --
Re: Version of autoconf for releases?
On Tue, 2012-02-07 at 00:43 +, 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?
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
