You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by je...@apache.org on 2001/08/01 22:47:13 UTC
cvs commit: apr-util/xml/expat buildconf buildconf.sh
jerenkrantz 01/08/01 13:47:13
Modified: . .cvsignore CHANGES configure.in
build apu-conf.m4
Added: . buildconf
xml/expat buildconf
Removed: . buildconf.sh
xml/expat buildconf.sh
Log:
Make APR-util configure script rely on APR. This removes the locally
generated copy of libtool. Fix up how we call the expat configure
script. Generate config.nice file.
Also, general cleanups of macros that we no longer need to call in
APR-util as APR already figures these out for us.
- Rename buildconf.sh to buildconf
- Switches to APR_ADDTO for most of the variables
- Adds config.nice support to apr-util (yay!)
- Removes libtool generation in apr-util. rbb's recent commit made it so
that we would use APR's libtool, but he didn't remove the generation of
it. Expat still generates a libtool, but I may remove it from there
(but I am leery of branching too much from the official Expat version).
- Fix condition where we would run expat's configure twice.
Revision Changes Path
1.8 +1 -0 apr-util/.cvsignore
Index: .cvsignore
===================================================================
RCS file: /home/cvs/apr-util/.cvsignore,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- .cvsignore 2001/07/26 23:15:12 1.7
+++ .cvsignore 2001/08/01 20:47:12 1.8
@@ -4,6 +4,7 @@
config.cache
config.log
config.status
+config.nice
configure
libtool
libaprutil.la
1.24 +5 -0 apr-util/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/apr-util/CHANGES,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- CHANGES 2001/07/24 20:36:03 1.23
+++ CHANGES 2001/08/01 20:47:12 1.24
@@ -1,5 +1,10 @@
Changes with APR-util b1
+ *) Make APR-util configure script rely on APR. This removes the locally
+ generated copy of libtool and uses the one in APR. Fix up how we
+ call the expat configure script. Generate config.nice file.
+ [Justin Erenkrantz]
+
*) The apr_bucket lengths are now consistently apr_size_t, while any
apr_brigade lengths (short of a read) are consistently apr_off_t.
This is required for APR_HAS_LARGE_FILES handling. [William Rowe]
1.30 +26 -61 apr-util/configure.in
Index: configure.in
===================================================================
RCS file: /home/cvs/apr-util/configure.in,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- configure.in 2001/07/30 15:59:02 1.29
+++ configure.in 2001/08/01 20:47:12 1.30
@@ -8,17 +8,21 @@
AC_CONFIG_HEADER(include/private/apu_config.h)
AC_CONFIG_AUX_DIR(../apr/build)
+sinclude(build/apu-conf.m4)
+sinclude(../apr/build/libtool.m4)
+sinclude(../apr/build/apr_common.m4)
+
+dnl Generate ./config.nice for reproducing runs of configure
+dnl
+APR_CONFIG_NICE(config.nice)
+
+dnl # Some initial steps for configuration. We setup the default directory
+dnl # and which files are to be configured.
+
dnl Absolute source/build directory
abs_srcdir=`(cd $srcdir && pwd)`
abs_builddir=`pwd`
-sinclude(build/apu-conf.m4)
-sinclude(../apr/build/libtool.m4)
-
-AC_PROG_CC
-AC_PROG_AWK
-AC_CHECK_PROG(RM, rm, rm)
-
if test "$abs_builddir" != "$abs_srcdir"; then
USE_VPATH=1
fi
@@ -34,10 +38,10 @@
dnl
dnl set up the compilation flags and stuff
dnl
-INCLUDES="$INCLUDES -I\$(top_builddir)/include/private -I\$(top_builddir)/include"
+APR_ADDTO(INCLUDES, [-I\$(top_builddir)/include/private -I\$(top_builddir)/include])
if test -n "$USE_VPATH"; then
- INCLUDES="$INCLUDES -I\$(top_srcdir)/include"
+ APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/include])
fi
dnl
@@ -48,15 +52,14 @@
APU_FIND_APR
APU_CHECK_DBM
APU_FIND_EXPAT
-
-INCLUDES="$INCLUDES $APR_INCLUDES"
-dnl
-dnl prep libtool
-dnl
-echo "performing libtool configuration..."
+dnl Add in the INCLUDES from APR
+APR_ADDTO(INCLUDES, [$APR_INCLUDES])
+so_ext=$APR_SO_EXT
+lib_target=$APR_LIB_TARGET
+AC_SUBST(so_ext)
+AC_SUBST(lib_target)
-AC_CANONICAL_SYSTEM
LDFLAGS=""
EXPAT_LINK=""
case "$host_alias" in
@@ -71,51 +74,13 @@
;;
esac
-dnl AC_PROG_LIBTOOL can't be invoked more than once, so this
-dnl logic can't be combined with the previous case statement
-
-case "$host_alias" in
-*os2*)
- # Use a custom-made libtool replacement
- echo "using aplibtool"
- LIBTOOL="$APR_SOURCE_DIR/build/aplibtool"
- ;;
-*) dnl libtoolize requires that the following not be indented
-AC_PROG_LIBTOOL
- if test "x$LTFLAGS" = "x"; then
- LTFLAGS='--silent'
- fi
- ;;
-esac
-
-AC_ARG_ENABLE(libtool, [--with-libtool use libtool to link the library],
- [ use_libtool=$withval ], [ use_libtool="yes" ] )
-
-if test "x$use_libtool" = "xyes"; then
- lt_compile='$(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) -c $< && touch $@'
- link='$(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(LDFLAGS) -o $@'
- so_ext='lo'
- lib_target='-rpath $(libdir) $$objects'
-else
- lt_compile='$(COMPILE) -c $<'
- link='$(AR) cr $(TARGET_LIB) $$objects; $(RANLIB) $(TARGET_LIB)'
- so_ext='o'
- lib_target=''
-fi
-
-AC_SUBST(lt_compile)
-AC_SUBST(link)
-AC_SUBST(so_ext)
-AC_SUBST(lib_target)
-AC_SUBST(LTFLAGS)
-AC_SUBST(LT_LDFLAGS)
AC_SUBST(EXPAT_LINK)
dnl
dnl Prep all the flags and stuff for compilation and export to other builds
dnl
-CFLAGS="$CFLAGS $INCLUDES $APR_EXPORT_CFLAGS $APR_EXPORT_CPPFLAGS"
-LIBS="$LIBS $APR_EXPORT_LIBS"
+APR_ADDTO(CFLAGS, [$CFLAGS $INCLUDES $APR_EXPORT_CFLAGS $APR_EXPORT_CPPFLAGS])
+APR_ADDTO(LIBS, [$APR_EXPORT_LIBS])
AC_SUBST(APRUTIL_EXPORT_LIBS)
AC_SUBST(LDFLAGS)
@@ -139,12 +104,12 @@
dnl
dnl everthing is done.
-MAKEFILES=" Makefile buckets/Makefile crypto/Makefile dbm/Makefile dbm/sdbm/Makefile encoding/Makefile hooks/Makefile uri/Makefile xml/Makefile misc/Makefile $test_Makefile"
+MAKEFILES="Makefile buckets/Makefile crypto/Makefile dbm/Makefile dbm/sdbm/Makefile encoding/Makefile hooks/Makefile uri/Makefile xml/Makefile misc/Makefile $test_Makefile"
AC_OUTPUT([
- export_vars.sh
- include/private/apu_select_dbm.h
- include/apu.h
- $MAKEFILES
+ export_vars.sh
+ include/private/apu_select_dbm.h
+ include/apu.h
+ $MAKEFILES
])
dnl #----------------------------- Fixup Makefiles for VPATH support
1.1 apr-util/buildconf
Index: buildconf
===================================================================
#!/bin/sh
#
# Generate the autoconf header (include/apu_config.h) and ./configure
#
echo "Creating include/private/apu_config.h ..."
autoheader
echo "Creating configure ..."
### do some work to toss config.cache?
if autoconf; then
:
else
echo "autoconf failed"
exit 1
fi
#
# If Expat has been bundled, then go and configure the thing
#
if test -d xml/expat; then
echo "Invoking xml/expat/buildconf ..."
(cd xml/expat; ./buildconf)
fi
### expat-cvs (from SourceForge's CVS) does not have a buildconf.sh (yet)
1.11 +5 -4 apr-util/build/apu-conf.m4
Index: apu-conf.m4
===================================================================
RCS file: /home/cvs/apr-util/build/apu-conf.m4,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- apu-conf.m4 2001/07/09 02:30:54 1.10
+++ apu-conf.m4 2001/08/01 20:47:13 1.11
@@ -393,7 +393,7 @@
expat_include_dir=$top_builddir/$bundled_subdir/lib
expat_libs=$top_builddir/$bundled_subdir/lib/libexpat.la
APR_XML_SUBDIRS="`echo $bundled_subdir | sed -e 's%xml/%%'`"
-fi
+else
if test "$expat_include_dir" = "$srcdir/xml/expat/include" -o "$expat_include_dir" = "$srcdir/xml/expat/lib"; then
dnl This is a bit of a hack. This only works because we know that
dnl we are working with the bundled version of the software.
@@ -403,10 +403,11 @@
expat_libs=$top_builddir/$bundled_subdir/lib/libexpat.la
APR_XML_SUBDIRS="`echo $bundled_subdir | sed -e 's%xml/%%'`"
fi
+fi
AC_SUBST(APR_XML_SUBDIRS)
-INCLUDES="$INCLUDES -I$expat_include_dir"
-LIBS="$LIBS $expat_libs"
-APRUTIL_EXPORT_LIBS="$APRUTIL_EXPORT_LIBS $expat_libs"
+APR_ADDTO(INCLUDES, [-I$expat_include_dir])
+APR_ADDTO(LIBS, [$expat_libs])
+APR_ADDTO(APRUTIL_EXPORT_LIBS, [$expat_libs])
dnl ### export the Expat includes?
])
1.1 apr-util/xml/expat/buildconf
Index: buildconf
===================================================================
#! /bin/sh
#
# Build aclocal.m4 from libtool's libtool.m4
#
libtoolize=`conftools/PrintPath glibtoolize libtoolize`
if [ "x$libtoolize" = "x" ]; then
echo "libtoolize not found in path"
exit 1
fi
ltpath=`dirname $libtoolize`
ltfile=`cd $ltpath/../share/aclocal ; pwd`/libtool.m4
echo "Incorporating $ltfile into aclocal.m4 ..."
echo "dnl THIS FILE IS AUTOMATICALLY GENERATED BY buildconf.sh" > aclocal.m4
echo "dnl edits here will be lost" >> aclocal.m4
cat $ltfile >> aclocal.m4
cross_compile_warning="warning: AC_TRY_RUN called without default to allow cross compiling"
#
# Create the libtool helper files
#
# Note: we always replace the files, and we copy (rather than link) them.
#
echo "Copying libtool helper files ..."
$libtoolize --force --copy
#
# Generate the autoconf header template (config.h.in) and ./configure
#
echo "Creating config.h.in ..."
autoheader 2>&1 | grep -v "$cross_compile_warning"
echo "Creating configure ..."
### do some work to toss config.cache?
autoconf 2>&1 | grep -v "$cross_compile_warning"
exit 0
Re: cvs commit: apr-util/xml/expat buildconf buildconf.sh
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 02, 2001 at 01:58:04PM -0700, Justin Erenkrantz wrote:
> On Thu, Aug 02, 2001 at 01:31:00PM -0700, Greg Stein wrote:
> > On Wed, Aug 01, 2001 at 08:47:13PM -0000, jerenkrantz@apache.org wrote:
> > > jerenkrantz 01/08/01 13:47:13
> > >
> > > Modified: . .cvsignore CHANGES configure.in
> > > build apu-conf.m4
> > > Added: . buildconf
> > > xml/expat buildconf
> > > Removed: . buildconf.sh
> > > xml/expat buildconf.sh
> > >...
> > > - Removes libtool generation in apr-util. rbb's recent commit made it so
> > > that we would use APR's libtool, but he didn't remove the generation of
> > > it. Expat still generates a libtool, but I may remove it from there
> > > (but I am leery of branching too much from the official Expat version).
> >
> > Changing the name of that file will make it much more difficult to apply
> > fixes back and forth between the two. Tossing libtool might not be too bad,
> > but it does seem like a marginal optimization -- it will only be used when
> > somebody doesn't have an expat on their system.
>
> Did we add the buildconf.sh or is that a part of the official expat
> repository?
Part of the official repository. I put it there :-)
>...
> I don't really plan on removing libtool from expat. It was just a
> thought. We seem to have out-of-date config.guess and libtool in
> our bundled expat which causes problem with newer OSes (Darwin?).
There are a lot of build/config fixes that I need to do to Expat so that
another Expat release can be made (1.95.2 was done last week; this month
will see a 1.95.3). Part of that will be to upgrade the libtool in there,
and to integrate changes back/forth between our copy and the official one.
Our copy has some good work in the build/config that can migrate over to the
official Expat (the ASF is good at that part :-).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/xml/expat buildconf buildconf.sh
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Aug 02, 2001 at 01:31:00PM -0700, Greg Stein wrote:
> On Wed, Aug 01, 2001 at 08:47:13PM -0000, jerenkrantz@apache.org wrote:
> > jerenkrantz 01/08/01 13:47:13
> >
> > Modified: . .cvsignore CHANGES configure.in
> > build apu-conf.m4
> > Added: . buildconf
> > xml/expat buildconf
> > Removed: . buildconf.sh
> > xml/expat buildconf.sh
> >...
> > - Removes libtool generation in apr-util. rbb's recent commit made it so
> > that we would use APR's libtool, but he didn't remove the generation of
> > it. Expat still generates a libtool, but I may remove it from there
> > (but I am leery of branching too much from the official Expat version).
>
> Changing the name of that file will make it much more difficult to apply
> fixes back and forth between the two. Tossing libtool might not be too bad,
> but it does seem like a marginal optimization -- it will only be used when
> somebody doesn't have an expat on their system.
Did we add the buildconf.sh or is that a part of the official expat
repository? If it is a part of expat, I'll revert back to
buildconf.sh for xml/expat. I'd like to keep apr-util as buildconf
since that matches apr and httpd-2.0.
I don't really plan on removing libtool from expat. It was just a
thought. We seem to have out-of-date config.guess and libtool in
our bundled expat which causes problem with newer OSes (Darwin?).
-- justin
Re: cvs commit: apr-util/xml/expat buildconf buildconf.sh
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 2 Aug 2001, Greg Stein wrote:
> (2) is flat out wrong: you need to "cvs rm" it so the "state" is correct
> within the file. It needs to be "dead" rather than just moved to the Attic.
Oops, yeah, what you said. =-)
> And the technique is also prone to error. Even tho you remove the tags,
> checking out by date will create spurious files (i.e. the "new" file will
> appear in old checkouts).
>
> "cvs add" and "cvs rm" with a pointer in the new file to the old is the
> safest all around.
Whatever. We've typically kept the history when we did this in the past,
but I don't much care.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: apr-util/xml/expat buildconf buildconf.sh
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 02, 2001 at 04:56:45PM -0400, Cliff Woolley wrote:
>...
> BTW - The spiffy cool way to do file renames and get history preserved is
> as follows:
>
> (1) copy the ,v file to its new name
> (2) move the old ,v file to the Attic
> (3) remove all tags from the new ,v file
No... that is borken.
(2) is flat out wrong: you need to "cvs rm" it so the "state" is correct
within the file. It needs to be "dead" rather than just moved to the Attic.
And the technique is also prone to error. Even tho you remove the tags,
checking out by date will create spurious files (i.e. the "new" file will
appear in old checkouts).
"cvs add" and "cvs rm" with a pointer in the new file to the old is the
safest all around.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/xml/expat buildconf buildconf.sh
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 2 Aug 2001, Greg Stein wrote:
> On Wed, Aug 01, 2001 at 08:47:13PM -0000, jerenkrantz@apache.org wrote:
> > jerenkrantz 01/08/01 13:47:13
> >
> > Modified: . .cvsignore CHANGES configure.in
> > build apu-conf.m4
> > Added: . buildconf
> > xml/expat buildconf
> > Removed: . buildconf.sh
> > xml/expat buildconf.sh
> >...
> > - Removes libtool generation in apr-util. rbb's recent commit made it so
> > that we would use APR's libtool, but he didn't remove the generation of
> > it. Expat still generates a libtool, but I may remove it from there
> > (but I am leery of branching too much from the official Expat version).
>
> Changing the name of that file will make it much more difficult to apply
> fixes back and forth between the two. Tossing libtool might not be too bad,
> but it does seem like a marginal optimization -- it will only be used when
> somebody doesn't have an expat on their system.
Yeah... I'm -0.5 for changing stuff like that in Expat. Don't get me
wrong... ++1 for changing it in apr-util itself. =-)
BTW - The spiffy cool way to do file renames and get history preserved is
as follows:
(1) copy the ,v file to its new name
(2) move the old ,v file to the Attic
(3) remove all tags from the new ,v file
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: apr-util/xml/expat buildconf buildconf.sh
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 01, 2001 at 08:47:13PM -0000, jerenkrantz@apache.org wrote:
> jerenkrantz 01/08/01 13:47:13
>
> Modified: . .cvsignore CHANGES configure.in
> build apu-conf.m4
> Added: . buildconf
> xml/expat buildconf
> Removed: . buildconf.sh
> xml/expat buildconf.sh
>...
> - Removes libtool generation in apr-util. rbb's recent commit made it so
> that we would use APR's libtool, but he didn't remove the generation of
> it. Expat still generates a libtool, but I may remove it from there
> (but I am leery of branching too much from the official Expat version).
Changing the name of that file will make it much more difficult to apply
fixes back and forth between the two. Tossing libtool might not be too bad,
but it does seem like a marginal optimization -- it will only be used when
somebody doesn't have an expat on their system.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/