You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by bj...@apache.org on 2001/03/29 17:53:26 UTC
cvs commit: apr-util/xml/expat configure.in
bjh 01/03/29 07:53:26
Modified: . configure.in
xml/expat configure.in
Log:
Use aplibtool on OS/2.
Revision Changes Path
1.15 +12 -1 apr-util/configure.in
Index: configure.in
===================================================================
RCS file: /home/cvs/apr-util/configure.in,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- configure.in 2001/03/09 14:02:45 1.14
+++ configure.in 2001/03/29 15:53:24 1.15
@@ -39,7 +39,18 @@
dnl prep libtool
dnl
echo "performing libtool configuration..."
-AC_PROG_LIBTOOL
+
+AC_CANONICAL_SYSTEM
+case "$host_alias" in
+*os2*)
+ # Use a custom made libtool replacement
+ echo "using aplibtool"
+ LIBTOOL="$APR_SOURCE_DIR/build/aplibtool"
+ ;;
+*)
+ AC_PROG_LIBTOOL
+ ;;
+esac
dnl
dnl grab flags from APR.
1.2 +12 -2 apr-util/xml/expat/configure.in
Index: configure.in
===================================================================
RCS file: /home/cvs/apr-util/xml/expat/configure.in,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- configure.in 2001/02/28 14:41:25 1.1
+++ configure.in 2001/03/29 15:53:26 1.2
@@ -45,8 +45,18 @@
AC_CONFIG_HEADER(config.h)
-AC_LIBTOOL_WIN32_DLL
-AC_PROG_LIBTOOL
+AC_CANONICAL_SYSTEM
+case "$host_alias" in
+*os2*)
+ # Use a custom made libtool replacement
+ echo Using aplibtool
+ LIBTOOL="$srcdir/../../../apr/build/aplibtool"
+ ;;
+*)
+ AC_LIBTOOL_WIN32_DLL
+ AC_PROG_LIBTOOL
+ ;;
+esac
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
Re: cvs commit: apr-util/xml/expat configure.in
Posted by Jeff Trawick <tr...@bellsouth.net>.
For reasons I can't explain, on systems with real libtool the minor
changes below result in a new buildconf message ("Remember to add
`AM_PROG_LIBTOOL' to `configure.in'.") for both configure.in files.
If I move the AC_PROG_LIBTOOL invocation to the beginning of the line
(i.e., just delete the four spaces) the messages go away.
The same spaces in apr/configure.in don't cause the message to be
generated.
Weird, huh?
bjh@apache.org writes:
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr-util/configure.in,v
...
> -AC_PROG_LIBTOOL
> +
> +AC_CANONICAL_SYSTEM
> +case "$host_alias" in
> +*os2*)
> + # Use a custom made libtool replacement
> + echo "using aplibtool"
> + LIBTOOL="$APR_SOURCE_DIR/build/aplibtool"
> + ;;
> +*)
> + AC_PROG_LIBTOOL
> + ;;
> +esac
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr-util/xml/expat/configure.in,v
...
> -AC_LIBTOOL_WIN32_DLL
> -AC_PROG_LIBTOOL
> +AC_CANONICAL_SYSTEM
> +case "$host_alias" in
> +*os2*)
> + # Use a custom made libtool replacement
> + echo Using aplibtool
> + LIBTOOL="$srcdir/../../../apr/build/aplibtool"
> + ;;
> +*)
> + AC_LIBTOOL_WIN32_DLL
> + AC_PROG_LIBTOOL
> + ;;
> +esac
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr-util/xml/expat configure.in
Posted by Jeff Trawick <tr...@bellsouth.net>.
"Brian Havard" <br...@kheldar.apana.org.au> writes:
> On 29 Mar 2001 11:07:31 -0500, Jeff Trawick wrote:
>
> >It seemed cleaner to me to provide an empty AC_LIBTOOL_WIN32_DLL macro
> >than to change the expat build.
>
> Err, actually it's just moved, not removed, into the "everything but OS/2"
> section (see below). It could probably have stayed where it was come to
> think of it. If it doesn't hurt on unix it probably won't hurt OS/2 either.
> I've no idea what it does though.
I didn't say you removed it. I'm saying that the change and
OS/2-specific path wasn't needed.
My point is that you can (and IMHO should) minimize special-case logic
in the apache/apr/expat/whatever build to deal with your libtool.
What happens when your libtool is taught to handle another system?
These same sections of build code have to be updated again.
FYI... AC_LIBTOOL_WIN32_DLL certainly doesn't hurt on Unix. I have
no idea what it does either, but an empty macro works fine for me on
OS/390.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr-util/xml/expat configure.in
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On 29 Mar 2001 11:07:31 -0500, Jeff Trawick wrote:
>bjh@apache.org writes:
[...]
>> Index: configure.in
>> ===================================================================
>> RCS file: /home/cvs/apr-util/xml/expat/configure.in,v
>> retrieving revision 1.1
>> retrieving revision 1.2
>> diff -u -r1.1 -r1.2
>> --- configure.in 2001/02/28 14:41:25 1.1
>> +++ configure.in 2001/03/29 15:53:26 1.2
>> @@ -45,8 +45,18 @@
>>
>> AC_CONFIG_HEADER(config.h)
>>
>> -AC_LIBTOOL_WIN32_DLL
>
>It seemed cleaner to me to provide an empty AC_LIBTOOL_WIN32_DLL macro
>than to change the expat build.
Err, actually it's just moved, not removed, into the "everything but OS/2"
section (see below). It could probably have stayed where it was come to
think of it. If it doesn't hurt on unix it probably won't hurt OS/2 either.
I've no idea what it does though.
>> -AC_PROG_LIBTOOL
>> +AC_CANONICAL_SYSTEM
>> +case "$host_alias" in
>> +*os2*)
>> + # Use a custom made libtool replacement
>> + echo Using aplibtool
>> + LIBTOOL="$srcdir/../../../apr/build/aplibtool"
>> + ;;
>> +*)
>> + AC_LIBTOOL_WIN32_DLL
>> + AC_PROG_LIBTOOL
>> + ;;
>> +esac
>
>as before, do this in AC_PROG_LIBTOOL
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: cvs commit: apr-util/xml/expat configure.in
Posted by Jeff Trawick <tr...@bellsouth.net>.
bjh@apache.org writes:
> Modified: . configure.in
> xml/expat configure.in
> Log:
> Use aplibtool on OS/2.
>
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr-util/configure.in,v
> retrieving revision 1.14
> retrieving revision 1.15
> diff -u -r1.14 -r1.15
> --- configure.in 2001/03/09 14:02:45 1.14
> +++ configure.in 2001/03/29 15:53:24 1.15
> @@ -39,7 +39,18 @@
> dnl prep libtool
> dnl
> echo "performing libtool configuration..."
> -AC_PROG_LIBTOOL
> +
> +AC_CANONICAL_SYSTEM
> +case "$host_alias" in
> +*os2*)
> + # Use a custom made libtool replacement
> + echo "using aplibtool"
> + LIBTOOL="$APR_SOURCE_DIR/build/aplibtool"
> + ;;
> +*)
> + AC_PROG_LIBTOOL
> + ;;
> +esac
Same comment as before... just provide AC_PROG_LIBTOOL which does the
right thing...
> 1.2 +12 -2 apr-util/xml/expat/configure.in
>
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr-util/xml/expat/configure.in,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- configure.in 2001/02/28 14:41:25 1.1
> +++ configure.in 2001/03/29 15:53:26 1.2
> @@ -45,8 +45,18 @@
>
> AC_CONFIG_HEADER(config.h)
>
> -AC_LIBTOOL_WIN32_DLL
It seemed cleaner to me to provide an empty AC_LIBTOOL_WIN32_DLL macro
than to change the expat build.
> -AC_PROG_LIBTOOL
> +AC_CANONICAL_SYSTEM
> +case "$host_alias" in
> +*os2*)
> + # Use a custom made libtool replacement
> + echo Using aplibtool
> + LIBTOOL="$srcdir/../../../apr/build/aplibtool"
> + ;;
> +*)
> + AC_LIBTOOL_WIN32_DLL
> + AC_PROG_LIBTOOL
> + ;;
> +esac
as before, do this in AC_PROG_LIBTOOL
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...