Re: cvs commit: apr-util/xml/expat configure.in

2001-03-29 Thread Jeff Trawick 
[EMAIL PROTECTED] 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.in2001/03/09 14:02:45 1.14
>   +++ configure.in2001/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.in2001/02/28 14:41:25 1.1
>   +++ configure.in2001/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 | [EMAIL PROTECTED] | 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

2001-03-29 Thread Brian Havard 
On 29 Mar 2001 11:07:31 -0500, Jeff Trawick wrote:

>[EMAIL PROTECTED] 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!   |
 |  [EMAIL PROTECTED]  |  He's a very naughty boy!" - Life of Brian |
 --

Re: cvs commit: apr-util/xml/expat configure.in

2001-03-29 Thread Jeff Trawick 
"Brian Havard" <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | 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

2001-03-30 Thread Jeff Trawick 
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?

[EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | PGP public key at web site:
   http://www.geocities.com/SiliconValley/Park/9289/
 Born in Roswell... married an alien...