Re: cvs commit: apr-util/xml/expat configure.in
[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
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
"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
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...