You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Blair Zajac <bl...@orcaware.com> on 2002/02/14 08:40:47 UTC

Apply these patches

Hello,

I sent in two patches last Friday to fix/modify APRs behavior with autoconf
2.52{f,g}.  Can somebody apply one or both of them?  The subjects are

    [PATCH] build/buildcheck.sh: Do not accept autoconf 2.52f or greater

    [PATCH] Enabloe autoconf 2.52{f,g} builds

The first patches build/buildcheck.sh to complain about autoconf 2.52{f,g}
since these break the build due to an issue with top_builddir being a
relative path.  The second patch works around the problem.

The second should be applied because it doesn't break anything, while the
first could be additionally applied if there are other issues with autoconf
2.52{f,g} so APR shouldn't use it.

Best,
Blair

-- 
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/

Re: Apply these patches

Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Feb 14, 2002 at 11:11:58AM -0800, Blair Zajac wrote:
> OK.  Here's a patch to get autoconf 2.52f+ working (the previous one
> didn't work).  I've tested this against autoconf 2.13, 2.52d, 2.52h and
> they all work.

Committed.  Thanks.  -- justin


Re: Apply these patches

Posted by Blair Zajac <bl...@orcaware.com>.
Justin Erenkrantz wrote:
> 
> On Wed, Feb 13, 2002 at 11:40:47PM -0800, Blair Zajac wrote:
> > Hello,
> >
> > I sent in two patches last Friday to fix/modify APRs behavior with autoconf
> > 2.52{f,g}.  Can somebody apply one or both of them?  The subjects are
> >
> >     [PATCH] build/buildcheck.sh: Do not accept autoconf 2.52f or greater
> >
> >     [PATCH] Enabloe autoconf 2.52{f,g} builds
> 
> Your second patch did more than just enabling autoconf 2.52{f,g}
> builds.  It also did a style reformat which made it hard to see
> what you really changed.  While a style reformat is often good,
> we request that all style changes are separate from functional
> changes.
> 
> Please re-submit a patch that only enables autoconf 2.52f+ and we
> can review it.  It also doesn't help that I'm probably the person
> who would normally review this sort of thing and I've been busy
> trying to get .32 out the door.  -- justin

OK.  Here's a patch to get autoconf 2.52f+ working (the previous one
didn't work).  I've tested this against autoconf 2.13, 2.52d, 2.52h and
they all work.

It appears that some of the variables, abs_srcdir, are now used by
newer autoconfs and get special treatment.  For example, on APR HEAD

% grep abs_srcdir config.status
s,@abs_srcdir@,/export/home1/bzajac/tmp/apr,;t t
ac_abs_srcdir=`cd "$ac_dir" && cd $ac_srcdir && pwd`
s,@abs_srcdir@,$ac_abs_srcdir,;t t
ac_abs_srcdir=`cd "$ac_dir" && cd $ac_srcdir && pwd`

The patch renames abs_{src,build}dir to apr_{src,build}dir to avoid
collisions.

Best,
Blair

-- 
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/




Index: APRVARS.in
===================================================================
RCS file: /home/cvspublic/apr/APRVARS.in,v
retrieving revision 1.11
diff -u -r1.11 APRVARS.in
--- APRVARS.in	3 Dec 2001 18:00:04 -0000	1.11
+++ APRVARS.in	14 Feb 2002 18:55:11 -0000
@@ -8,7 +8,7 @@
 EXTRA_INCLUDES="@EXTRA_INCLUDES@"
 LIBTOOL_LIBS="@LIBTOOL_LIBS@"
 SHLIBPATH_VAR="@shlibpath_var@"
-APR_SOURCE_DIR="@abs_srcdir@"
+APR_SOURCE_DIR="@apr_srcdir@"
 APR_SO_EXT="@so_ext@"
 APR_LIB_TARGET="@export_lib_target@"
 
Index: CHANGES
===================================================================
RCS file: /home/cvspublic/apr/CHANGES,v
retrieving revision 1.221
diff -u -r1.221 CHANGES
--- CHANGES	13 Feb 2002 16:39:28 -0000	1.221
+++ CHANGES	14 Feb 2002 18:55:11 -0000
@@ -1,6 +1,9 @@
-Changes with APR b1  
+Changes with APR b1
 
-  *) added new functions for atomic operations. These are experimental
+  *) Enable autoconf 2.52{f,g} build support.
+     [Blair Zajac <bl...@orcaware.com>]
+
+  *) Added new functions for atomic operations. These are experimental
      at the moment, so use in apps is discouraged [Ian Holsman]
 
   *) Correct serious problems with the Win32 apr_file_dup2 
Index: apr-config.in
===================================================================
RCS file: /home/cvspublic/apr/apr-config.in,v
retrieving revision 1.10
diff -u -r1.10 apr-config.in
--- apr-config.in	8 Feb 2002 21:03:25 -0000	1.10
+++ apr-config.in	14 Feb 2002 18:55:11 -0000
@@ -70,7 +70,7 @@
 LIBS="@EXTRA_LIBS@"
 EXTRA_INCLUDES="@EXTRA_INCLUDES@"
 SHLIBPATH_VAR="@shlibpath_var@"
-APR_SOURCE_DIR="@abs_srcdir@"
+APR_SOURCE_DIR="@apr_srcdir@"
 APR_SO_EXT="@so_ext@"
 APR_LIB_TARGET="@export_lib_target@"
 
Index: configure.in
===================================================================
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.406
diff -u -r1.406 configure.in
--- configure.in	12 Feb 2002 21:51:30 -0000	1.406
+++ configure.in	14 Feb 2002 18:55:11 -0000
@@ -46,25 +46,26 @@
 APR_PRELOAD
 
 dnl Absolute source/build directory
-abs_srcdir=`(cd $srcdir && pwd)`
-abs_builddir=`pwd`
+apr_srcdir=`(cd $srcdir && pwd)`
+apr_builddir=`pwd`
+AC_SUBST(apr_srcdir)
+AC_SUBST(apr_builddir)
 
-if test "$abs_builddir" != "$abs_srcdir"; then
+if test "$apr_builddir" != "$apr_srcdir"; then
   USE_VPATH=1
 fi
 
 dnl Libtool might need this symbol -- it must point to the location of
 dnl the generated libtool script (not necessarily the "top" build dir).
 dnl
-top_builddir="$abs_builddir"
+top_builddir="$apr_builddir"
 AC_SUBST(top_builddir)
-AC_SUBST(abs_srcdir)
 
 dnl Directory containing apr build macros, helpers, and make rules
 dnl NOTE: make rules (rules.mk) will be in the builddir for vpath
 dnl
-apr_buildout=$abs_builddir/build
-apr_builders=$abs_srcdir/build
+apr_buildout=$apr_builddir/build
+apr_builders=$apr_srcdir/build
 AC_SUBST(apr_builders)
 
 MKDIR=$apr_builders/mkdir.sh
@@ -109,7 +110,7 @@
         LTFLAGS='--silent'
     fi
     dnl get libtool's setting of shlibpath_var
-    eval `grep "^shlibpath_var=[[A-Z_]]\+$" $abs_builddir/libtool`
+    eval `grep "^shlibpath_var=[[A-Z_]]\+$" $apr_builddir/libtool`
     ;;
 esac
 
@@ -1564,8 +1565,8 @@
   for makefile in $MAKEFILE1 $MAKEFILE2 $MAKEFILE3; do
     dir=`echo $makefile|sed 's%[^/][^/]*$%%'`
     (cat <<EOF
-srcdir = $abs_srcdir/$dir
-VPATH  = $abs_srcdir/$dir
+srcdir = $apr_srcdir/$dir
+VPATH  = $apr_srcdir/$dir
 
 EOF
 )    |  cat - $makefile | \
Index: build/rules.mk.in
===================================================================
RCS file: /home/cvspublic/apr/build/rules.mk.in,v
retrieving revision 1.21
diff -u -r1.21 rules.mk.in
--- build/rules.mk.in	29 Oct 2001 12:47:13 -0000	1.21
+++ build/rules.mk.in	14 Feb 2002 18:55:11 -0000
@@ -61,7 +61,7 @@
 #
 # Configuration variables
 #
-apr_builddir=@top_builddir@
+apr_builddir=@apr_builddir@
 apr_builders=@apr_builders@
 
 CC=@CC@

Re: Apply these patches

Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Feb 13, 2002 at 11:40:47PM -0800, Blair Zajac wrote:
> Hello,
> 
> I sent in two patches last Friday to fix/modify APRs behavior with autoconf
> 2.52{f,g}.  Can somebody apply one or both of them?  The subjects are
> 
>     [PATCH] build/buildcheck.sh: Do not accept autoconf 2.52f or greater
> 
>     [PATCH] Enabloe autoconf 2.52{f,g} builds

Your second patch did more than just enabling autoconf 2.52{f,g}
builds.  It also did a style reformat which made it hard to see
what you really changed.  While a style reformat is often good,
we request that all style changes are separate from functional
changes.

Please re-submit a patch that only enables autoconf 2.52f+ and we
can review it.  It also doesn't help that I'm probably the person
who would normally review this sort of thing and I've been busy
trying to get .32 out the door.  -- justin