You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by dr...@apache.org on 2001/08/31 11:47:54 UTC
cvs commit: apr-util configure.in Makefile.in
dreid 01/08/31 02:47:53
Modified: srclib Makefile.in
. configure.in Makefile.in
Log:
With my normal sense of missing the boat :)
This gets the build working on BeOS again :) Apologies for the delay :(
Jeff changed the order of apr-util and apr to solve a "cleaning" issue but
that makes me uncomfortable as apr-util is dependant on apr, so if we clean
apr-util we shouldn't be altering anything in apr. If I decide to rebuild
apr-util then apr should still be buildable. Sorry Jeff but I think we need
a different solution :(
Submitted by: Peter Schultz <pe...@beforever.com>
Revision Changes Path
1.11 +1 -1 httpd-2.0/srclib/Makefile.in
Index: Makefile.in
===================================================================
RCS file: /home/cvs/httpd-2.0/srclib/Makefile.in,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Makefile.in 2001/07/31 12:19:55 1.10
+++ Makefile.in 2001/08/31 09:47:53 1.11
@@ -1,4 +1,4 @@
-SUBDIRS = apr-util apr $(AP_LIB_DIRS) pcre
+SUBDIRS = apr apr-util $(AP_LIB_DIRS) pcre
include $(top_srcdir)/build/rules.mk
1.34 +7 -8 apr-util/configure.in
Index: configure.in
===================================================================
RCS file: /home/cvs/apr-util/configure.in,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- configure.in 2001/08/24 03:18:54 1.33
+++ configure.in 2001/08/31 09:47:53 1.34
@@ -60,21 +60,20 @@
AC_SUBST(so_ext)
AC_SUBST(lib_target)
-LDFLAGS=""
-EXPAT_LINK=""
+EXTRA_OS_LINK=""
+host_alias=`uname -s`
case "$host_alias" in
-*beos*)
+*BeOS*)
# Horrible Hack !!!
- # if we're building a shared lib then we need to add in the
- # apr library to the build...
- LDFLAGS="$APR_SOURCE_DIR/libapr.la"
- EXPAT_LINK="\$(top_builddir)/xml/expat/lib/libexpat.so"
+ # if we're building on BeOS then we need to add in the
+ # apr and expat libraries to the build... Grrrr...
+ EXTRA_OS_LINK="$APR_SOURCE_DIR/libapr.la $top_builddir/xml/expat/lib/libexpat.la"
;;
*)
;;
esac
-AC_SUBST(EXPAT_LINK)
+AC_SUBST(EXTRA_OS_LINK)
dnl
dnl Prep all the flags and stuff for compilation and export to other builds
1.45 +1 -1 apr-util/Makefile.in
Index: Makefile.in
===================================================================
RCS file: /home/cvs/apr-util/Makefile.in,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- Makefile.in 2001/08/24 08:05:30 1.44
+++ Makefile.in 2001/08/31 09:47:53 1.45
@@ -50,7 +50,7 @@
$(TARGET_LIB):
@objects="`find $(SUBDIRS) -name expat -prune -o -name '*.@so_ext@' -print`"; \
- $(LINK) @lib_target@ @EXPAT_LINK@
+ $(LINK) @lib_target@ @EXTRA_OS_LINK@
delete-exports:
@if test -f $(TARGET_EXPORTS); then \
Re: cvs commit: apr-util configure.in Makefile.in
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 31 August 2001 09:43, Jeff Trawick wrote:
> Ryan Bloom <rb...@covalent.net> writes:
> > On Friday 31 August 2001 08:52, Jeff Trawick wrote:
> > > Ryan Bloom <rb...@covalent.net> writes:
> > > > On Friday 31 August 2001 07:48, Jeff Trawick wrote:
> > > >
> > > > -1 This is where we were before I made the change a few weeks
> > > > ago. APR-util relies on APR to build, duplicating the build logic
> > > > is a bad idea, because like all duplicate code, it opens up places
> > > > for bugs to hide.
> > >
> > > That's just plain silly. Copying a file from apr to apr-util doesn't
> > > introduce more places for bugs to hide, any more than copying a
> > > libtool-provided .m4 into one of our own does. And this sort of
> > > "duplication" has little relation to the changes you allude to.
> > >
> > > Do you have a real reason not to commit this, or alternatively, your
> > > own working solution you can commit?
> >
> > Yeah, the real reason, is that this is completely bogus.
>
> That's just stupid. I'm glad you want to solve the problem and I have
> no problem with your solution, but your veto was bullshit.
>
> The real reason is apparently that you have something you like better
> (I'm not saying that's good or bad). "Completely bogus" is not a
> reason to veto something.
>
> If you want to say "please wait before..." because you don't feel
> something is as good as it can be and you want to play with it first,
> feel free. I think everybody would respect that from anyone else.
No, having two copies of a file in two different directories is completely
bogus. I have always said that, and I will continue to say it. That is what
my veto was for, and I will continue to stand by it.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: apr-util configure.in Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:
> On Friday 31 August 2001 08:52, Jeff Trawick wrote:
> > Ryan Bloom <rb...@covalent.net> writes:
> > > On Friday 31 August 2001 07:48, Jeff Trawick wrote:
> > >
> > > -1 This is where we were before I made the change a few weeks
> > > ago. APR-util relies on APR to build, duplicating the build logic
> > > is a bad idea, because like all duplicate code, it opens up places
> > > for bugs to hide.
> >
> > That's just plain silly. Copying a file from apr to apr-util doesn't
> > introduce more places for bugs to hide, any more than copying a
> > libtool-provided .m4 into one of our own does. And this sort of
> > "duplication" has little relation to the changes you allude to.
> >
> > Do you have a real reason not to commit this, or alternatively, your
> > own working solution you can commit?
>
> Yeah, the real reason, is that this is completely bogus.
That's just stupid. I'm glad you want to solve the problem and I have
no problem with your solution, but your veto was bullshit.
The real reason is apparently that you have something you like better
(I'm not saying that's good or bad). "Completely bogus" is not a
reason to veto something.
If you want to say "please wait before..." because you don't feel
something is as good as it can be and you want to play with it first,
feel free. I think everybody would respect that from anyone else.
--
Jeff Trawick | trawick@attglobal.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 configure.in Makefile.in
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 31 August 2001 08:52, Jeff Trawick wrote:
> Ryan Bloom <rb...@covalent.net> writes:
> > On Friday 31 August 2001 07:48, Jeff Trawick wrote:
> >
> > -1 This is where we were before I made the change a few weeks
> > ago. APR-util relies on APR to build, duplicating the build logic
> > is a bad idea, because like all duplicate code, it opens up places
> > for bugs to hide.
>
> That's just plain silly. Copying a file from apr to apr-util doesn't
> introduce more places for bugs to hide, any more than copying a
> libtool-provided .m4 into one of our own does. And this sort of
> "duplication" has little relation to the changes you allude to.
>
> Do you have a real reason not to commit this, or alternatively, your
> own working solution you can commit?
Yeah, the real reason, is that this is completely bogus. The real solution is
to have different orderings for build and clean. This makes good sense,
because we are essentially saying APR has to be built before APR-util,
and APR has to be cleaned after APR-util.
I'll commit within ten minutes.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: apr-util configure.in Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:
> On Friday 31 August 2001 07:48, Jeff Trawick wrote:
>
> -1 This is where we were before I made the change a few weeks
> ago. APR-util relies on APR to build, duplicating the build logic
> is a bad idea, because like all duplicate code, it opens up places
> for bugs to hide.
That's just plain silly. Copying a file from apr to apr-util doesn't
introduce more places for bugs to hide, any more than copying a
libtool-provided .m4 into one of our own does. And this sort of
"duplication" has little relation to the changes you allude to.
Do you have a real reason not to commit this, or alternatively, your
own working solution you can commit?
--
Jeff Trawick | trawick@attglobal.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 configure.in Makefile.in
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 31 August 2001 07:48, Jeff Trawick wrote:
-1 This is where we were before I made the change a few weeks
ago. APR-util relies on APR to build, duplicating the build logic
is a bad idea, because like all duplicate code, it opens up places
for bugs to hide.
Ryan
> "William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> > Jeff,
> >
> > this will become a problem on Win32 as well, and it's pretty fragile.
> >
> > What if we institute a two-pass clean? Don't eliminate any
> > dependencies on the first go, and the distclean target can then mop up
> > the obvious (.mk targets, generated .h files, etc.) I think this would
> > be safer, all the way around. Trying to toggle build orders by model
> > will just get messier and messier.
>
> What I have implemented/tested was my second suggestion -- copy apr's
> rules.mk into the apr-util tree at configuration time. apr-util already
> requires that apr was configured, so there is no additional
> dependency.
>
> Since apr-util has its own copy of rules.mk, the includes in apr-util
> makefiles still work regardless of the order of apr and apr-util in
> srclib/Makefile.
>
> Cool? That is simpler than a two-pass clean, and avoids a wasted
> second pass for certain operations (like normal make).
>
> Here is the patch:
>
> Index: srclib/apr-util/Makefile.in
> ===================================================================
> RCS file: /home/cvspublic/apr-util/Makefile.in,v
> retrieving revision 1.45
> diff -u -r1.45 Makefile.in
> --- srclib/apr-util/Makefile.in 2001/08/31 09:47:53 1.45
> +++ srclib/apr-util/Makefile.in 2001/08/31 14:31:50
> @@ -17,7 +17,8 @@
> CLEAN_TARGETS = $(TARGET_EXPORTS)
> DISTCLEAN_TARGETS = config.cache config.log config.status libtool \
> include/private/apu_config.h include/private/apu_private.h \
> - include/private/apu_select_dbm.h include/apu.h export_vars.sh
> + include/private/apu_select_dbm.h include/apu.h export_vars.sh \
> + build/rules.mk
> EXTRACLEAN_TARGETS = configure aclocal.m4 include/private/apu_config.h.in
>
> prefix=@prefix@
> Index: srclib/apr-util/configure.in
> ===================================================================
> RCS file: /home/cvspublic/apr-util/configure.in,v
> retrieving revision 1.34
> diff -u -r1.34 configure.in
> --- srclib/apr-util/configure.in 2001/08/31 09:47:53 1.34
> +++ srclib/apr-util/configure.in 2001/08/31 14:31:50
> @@ -86,14 +86,26 @@
> APR_ADDTO(LIBS,[$APRUTIL_EXPORT_LIBS])
>
> dnl
> +dnl copy APR's build/rules.mk to our build directory; if we reference it
> +dnl from the APR directory then our "make *clean" is dependent on APR
> +dnl still being around
> +dnl
> +if cp $top_builddir/../apr/build/rules.mk $top_builddir/build/rules.mk;
> then + :
> +else
> + echo "Fatal error: APR hasn't been configured yet"
> + exit 1
> +fi
> +
> +dnl
> dnl BSD/OS (BSDi) needs to use a different include syntax in the Makefiles
> dnl
> case "$host_alias" in
> *bsdi*)
> - INCLUDE_RULES=".include \"$top_builddir/../apr/build/rules.mk\""
> + INCLUDE_RULES=".include \"$top_builddir/build/rules.mk\""
> ;;
> *)
> - INCLUDE_RULES="include $top_builddir/../apr/build/rules.mk"
> + INCLUDE_RULES="include $top_builddir/build/rules.mk"
> ;;
> esac
> AC_SUBST(INCLUDE_RULES)
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: apr-util configure.in Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> Jeff,
>
> this will become a problem on Win32 as well, and it's pretty fragile.
>
> What if we institute a two-pass clean? Don't eliminate any dependencies on the
> first go, and the distclean target can then mop up the obvious (.mk targets, generated
> .h files, etc.) I think this would be safer, all the way around. Trying to toggle
> build orders by model will just get messier and messier.
What I have implemented/tested was my second suggestion -- copy apr's
rules.mk into the apr-util tree at configuration time. apr-util already
requires that apr was configured, so there is no additional
dependency.
Since apr-util has its own copy of rules.mk, the includes in apr-util
makefiles still work regardless of the order of apr and apr-util in
srclib/Makefile.
Cool? That is simpler than a two-pass clean, and avoids a wasted
second pass for certain operations (like normal make).
Here is the patch:
Index: srclib/apr-util/Makefile.in
===================================================================
RCS file: /home/cvspublic/apr-util/Makefile.in,v
retrieving revision 1.45
diff -u -r1.45 Makefile.in
--- srclib/apr-util/Makefile.in 2001/08/31 09:47:53 1.45
+++ srclib/apr-util/Makefile.in 2001/08/31 14:31:50
@@ -17,7 +17,8 @@
CLEAN_TARGETS = $(TARGET_EXPORTS)
DISTCLEAN_TARGETS = config.cache config.log config.status libtool \
include/private/apu_config.h include/private/apu_private.h \
- include/private/apu_select_dbm.h include/apu.h export_vars.sh
+ include/private/apu_select_dbm.h include/apu.h export_vars.sh \
+ build/rules.mk
EXTRACLEAN_TARGETS = configure aclocal.m4 include/private/apu_config.h.in
prefix=@prefix@
Index: srclib/apr-util/configure.in
===================================================================
RCS file: /home/cvspublic/apr-util/configure.in,v
retrieving revision 1.34
diff -u -r1.34 configure.in
--- srclib/apr-util/configure.in 2001/08/31 09:47:53 1.34
+++ srclib/apr-util/configure.in 2001/08/31 14:31:50
@@ -86,14 +86,26 @@
APR_ADDTO(LIBS,[$APRUTIL_EXPORT_LIBS])
dnl
+dnl copy APR's build/rules.mk to our build directory; if we reference it
+dnl from the APR directory then our "make *clean" is dependent on APR
+dnl still being around
+dnl
+if cp $top_builddir/../apr/build/rules.mk $top_builddir/build/rules.mk; then
+ :
+else
+ echo "Fatal error: APR hasn't been configured yet"
+ exit 1
+fi
+
+dnl
dnl BSD/OS (BSDi) needs to use a different include syntax in the Makefiles
dnl
case "$host_alias" in
*bsdi*)
- INCLUDE_RULES=".include \"$top_builddir/../apr/build/rules.mk\""
+ INCLUDE_RULES=".include \"$top_builddir/build/rules.mk\""
;;
*)
- INCLUDE_RULES="include $top_builddir/../apr/build/rules.mk"
+ INCLUDE_RULES="include $top_builddir/build/rules.mk"
;;
esac
AC_SUBST(INCLUDE_RULES)
--
Jeff Trawick | trawick@attglobal.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 configure.in Makefile.in
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff,
this will become a problem on Win32 as well, and it's pretty fragile.
What if we institute a two-pass clean? Don't eliminate any dependencies on the
first go, and the distclean target can then mop up the obvious (.mk targets, generated
.h files, etc.) I think this would be safer, all the way around. Trying to toggle
build orders by model will just get messier and messier.
Bill
----- Original Message -----
From: "Jeff Trawick" <tr...@attglobal.net>
To: <de...@apr.apache.org>
Cc: <ap...@apache.org>
Sent: Friday, August 31, 2001 8:41 AM
Subject: Re: cvs commit: apr-util configure.in Makefile.in
> dreid@apache.org writes:
>
> > dreid 01/08/31 02:47:53
> >
> > Modified: srclib Makefile.in
> > . configure.in Makefile.in
> > Log:
> > With my normal sense of missing the boat :)
> >
> > This gets the build working on BeOS again :) Apologies for the delay :(
> >
> > Jeff changed the order of apr-util and apr to solve a "cleaning" issue but
> > that makes me uncomfortable as apr-util is dependant on apr, so if we clean
> > apr-util we shouldn't be altering anything in apr. If I decide to rebuild
> > apr-util then apr should still be buildable. Sorry Jeff but I think we need
> > a different solution :(
>
> Cleaning is extremely important :) It is mandatory to get a proper build
> anywhere. (Okay, the only real reason I care is that it keeps a
> stream of e-mails from hitting my inbox.)
>
> I think that the issue is that on BeOS apr-util is dependent on apr in
> a way that it isn't anywhere else (i.e., apr libraries have to be
> build before apr-util libraries only on BeOS).
>
> If this can't be avoided due to some BeOS limitation then the makefiles
> have to become a little more complicated so that
>
> 1) there is a different order for make vs. make *clean
>
> or
>
> 2) apr-util copies apr's rules.mk to one of its own directories to
> remove the *clean dependency on apr (I don't know if this is the
> only apr file in this category)
>
> apr-util's makefiles would include its copy, apr-util's makefiles
> would remove it during *clean
>
> Actually, #2 seems pretty simple.
>
> Comments anyone?
>
> --
> Jeff Trawick | trawick@attglobal.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 configure.in Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
dreid@apache.org writes:
> dreid 01/08/31 02:47:53
>
> Modified: srclib Makefile.in
> . configure.in Makefile.in
> Log:
> With my normal sense of missing the boat :)
>
> This gets the build working on BeOS again :) Apologies for the delay :(
>
> Jeff changed the order of apr-util and apr to solve a "cleaning" issue but
> that makes me uncomfortable as apr-util is dependant on apr, so if we clean
> apr-util we shouldn't be altering anything in apr. If I decide to rebuild
> apr-util then apr should still be buildable. Sorry Jeff but I think we need
> a different solution :(
Cleaning is extremely important :) It is mandatory to get a proper build
anywhere. (Okay, the only real reason I care is that it keeps a
stream of e-mails from hitting my inbox.)
I think that the issue is that on BeOS apr-util is dependent on apr in
a way that it isn't anywhere else (i.e., apr libraries have to be
build before apr-util libraries only on BeOS).
If this can't be avoided due to some BeOS limitation then the makefiles
have to become a little more complicated so that
1) there is a different order for make vs. make *clean
or
2) apr-util copies apr's rules.mk to one of its own directories to
remove the *clean dependency on apr (I don't know if this is the
only apr file in this category)
apr-util's makefiles would include its copy, apr-util's makefiles
would remove it during *clean
Actually, #2 seems pretty simple.
Comments anyone?
--
Jeff Trawick | trawick@attglobal.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 configure.in Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
dreid@apache.org writes:
> dreid 01/08/31 02:47:53
>
> Modified: srclib Makefile.in
> . configure.in Makefile.in
> Log:
> With my normal sense of missing the boat :)
>
> This gets the build working on BeOS again :) Apologies for the delay :(
>
> Jeff changed the order of apr-util and apr to solve a "cleaning" issue but
> that makes me uncomfortable as apr-util is dependant on apr, so if we clean
> apr-util we shouldn't be altering anything in apr. If I decide to rebuild
> apr-util then apr should still be buildable.
as I understand it: my change didn't cause anything to be altered in
apr when you clean apr-util; my change didn't affect whether or not
apr is buildable when you rebuild apr-util
--
Jeff Trawick | trawick@attglobal.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 configure.in Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
dreid@apache.org writes:
> dreid 01/08/31 02:47:53
>
> Modified: srclib Makefile.in
> . configure.in Makefile.in
> Log:
> With my normal sense of missing the boat :)
>
> This gets the build working on BeOS again :) Apologies for the delay :(
>
> Jeff changed the order of apr-util and apr to solve a "cleaning" issue but
> that makes me uncomfortable as apr-util is dependant on apr, so if we clean
> apr-util we shouldn't be altering anything in apr. If I decide to rebuild
> apr-util then apr should still be buildable.
as I understand it: my change didn't cause anything to be altered in
apr when you clean apr-util; my change didn't affect whether or not
apr is buildable when you rebuild apr-util
--
Jeff Trawick | trawick@attglobal.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 configure.in Makefile.in
Posted by Jeff Trawick <tr...@attglobal.net>.
dreid@apache.org writes:
> dreid 01/08/31 02:47:53
>
> Modified: srclib Makefile.in
> . configure.in Makefile.in
> Log:
> With my normal sense of missing the boat :)
>
> This gets the build working on BeOS again :) Apologies for the delay :(
>
> Jeff changed the order of apr-util and apr to solve a "cleaning" issue but
> that makes me uncomfortable as apr-util is dependant on apr, so if we clean
> apr-util we shouldn't be altering anything in apr. If I decide to rebuild
> apr-util then apr should still be buildable. Sorry Jeff but I think we need
> a different solution :(
Cleaning is extremely important :) It is mandatory to get a proper build
anywhere. (Okay, the only real reason I care is that it keeps a
stream of e-mails from hitting my inbox.)
I think that the issue is that on BeOS apr-util is dependent on apr in
a way that it isn't anywhere else (i.e., apr libraries have to be
build before apr-util libraries only on BeOS).
If this can't be avoided due to some BeOS limitation then the makefiles
have to become a little more complicated so that
1) there is a different order for make vs. make *clean
or
2) apr-util copies apr's rules.mk to one of its own directories to
remove the *clean dependency on apr (I don't know if this is the
only apr file in this category)
apr-util's makefiles would include its copy, apr-util's makefiles
would remove it during *clean
Actually, #2 seems pretty simple.
Comments anyone?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...