We have three levels of cleaning that need to be expressed:
1) clean out the .o files [before rebuilding]
2) clean out the results of running ./configure (restore everything to the
same point that you unpacked apache.org/dist/aprutil-1.0.tar.gz)
3) return to the point right after a CVS checkout
> > UGH! That's a real PITA. I was really hoping to not have to create
> > another set of DECLARE macros. :-(
>
> Not you... me.
I meant I was hoping Apache wouldn't NEED another set of macros. I was
hoping the two we have now would be enough.
Ryan
__
On Tue, Dec 05, 2000 at 04:04:09PM -0800, [EMAIL PROTECTED] wrote:
>
> > > UGH! That's a real PITA. I was really hoping to not have to create
> > > another set of DECLARE macros. :-(
> >
> > Not you... me.
>
> I meant I was hoping Apache wouldn't NEED another set of macros. I was
> hoping th
On Tue, Dec 05, 2000 at 02:28:31PM -0800, [EMAIL PROTECTED] wrote:
>...
> > All I'm asking for is the symbol name, is APR_UTIL_DECLARE too wordy (and if
> > so, would we rather use APU_DECLARE or APRU_DECLARE?, or even AU_DECLARE)
>
> I guess if we need another one, I would suggest APU_DECLARE.
I
On Wed, Dec 06, 2000 at 12:22:02AM +0100, Sascha Schumann wrote:
> On Tue, 5 Dec 2000 [EMAIL PROTECTED] wrote:
> >
> > > Modified:.Makefile.in
> > > Log:
> > > aprutil in the "distribution" form does not want to remove configure or
> > > aprutils.exports (these two files are p
> We have three levels of cleaning that need to be expressed:
>
> 1) clean out the .o files [before rebuilding]
> 2) clean out the results of running ./configure (restore everything to the
>same point that you unpacked apache.org/dist/aprutil-1.0.tar.gz)
> 3) return to the point right after a
On Tue, 5 Dec 2000, William A. Rowe, Jr. wrote:
> > From: Roy T. Fielding [mailto:[EMAIL PROTECTED]
> >
> > I am still categorically opposed to any prefix other than ap_ for
> > any symbols in any C library that is based on code developed by
> > the Apache projects. Including apr and apr-util, th
> No, distclean means "clean the directories in preparation of a release."
> For example, the one for rsync does
>
>distclean: clean
> rm -f config.h config.cache config.status Makefile
>
> I have seen "reallyclean" used as a target to remove all generated
> files, but it isn't a sta
On Tue, Dec 05, 2000 at 04:38:27PM -0800, [EMAIL PROTECTED] wrote:
>
> > We have three levels of cleaning that need to be expressed:
> >
> > 1) clean out the .o files [before rebuilding]
> > 2) clean out the results of running ./configure (restore everything to the
> >same point that you unpa
> > > 1) clean out the .o files [before rebuilding]
> > > 2) clean out the results of running ./configure (restore everything to the
> > >same point that you unpacked apache.org/dist/aprutil-1.0.tar.gz)
> > > 3) return to the point right after a CVS checkout
> >
> > Step 2 does not exist in A
> > We have three levels of cleaning that need to be expressed:
> >
> > 1) clean out the .o files [before rebuilding]
> > 2) clean out the results of running ./configure (restore everything to the
> >same point that you unpacked apache.org/dist/aprutil-1.0.tar.gz)
> > 3) return to the point ri
> *) move building of aprutil.exports into the top-level Makefile so that we
> can use APR's directory (rather than needing to pass it to buildconf.sh)
You can't do this. We need this file when running buildconf in Apache,
and it doesn't make any sense to do this each time we build apr-ut
[EMAIL PROTECTED] writes:
> > *) move building of aprutil.exports into the top-level Makefile so that we
> > can use APR's directory (rather than needing to pass it to
> > buildconf.sh)
>
> You can't do this. We need this file when running buildconf in Apache,
> and it doesn't make any s
> > > *) move building of aprutil.exports into the top-level Makefile so that
> > > we
> > > can use APR's directory (rather than needing to pass it to
> > > buildconf.sh)
> >
> > You can't do this. We need this file when running buildconf in Apache,
> > and it doesn't make any sense to
On 6 Dec 2000 [EMAIL PROTECTED] wrote:
> An alternate way to fix this problem is to explicitly break the bucket
> type out of the "type" structure in ap_bucketi and represent each bucket
> type with an enum.
We have been over this. This was part of the original design for the
buckets. Usi
> On 6 Dec 2000 [EMAIL PROTECTED] wrote:
>
> > An alternate way to fix this problem is to explicitly break the bucket
> > type out of the "type" structure in ap_bucketi and represent each bucket
> > type with an enum.
>
> We have been over this. This was part of the original design for th
On Tue, Dec 05, 2000 at 07:03:19PM -0800, [EMAIL PROTECTED] wrote:
>
> > *) move building of aprutil.exports into the top-level Makefile so that we
> > can use APR's directory (rather than needing to pass it to
> > buildconf.sh)
>
> You can't do this. We need this file when running build
> The file will only be built once. If you do a "make extraclean", then it
> will need to be built again. If the thing is built once, then it shouldn't
> really matter whether it is built at "buildconf.sh" or "make" time.
But it breaks the first time you try to configure Apache. That's no
good.
> > By moving it into the Makefile, we have access to the APR directory. The
> > parameter to buildconf.sh is a bit strange... our other buildconf scripts
> > don't do it (nor does autogen.sh in SVN). In some cases, APR can be found by
> > the configure script automatically, so nobody would need t
On Tue, Dec 05, 2000 at 03:38:45PM -0600, William A. Rowe, Jr. wrote:
>...
> Why do we add the additional complexity of a src/ directory within apr-util?
> Can't we keep to the same simplicity as apr itself? Suggesting, therefore,
> that we aught to have apr-util/buckets rather than apr-util/src/b
> From: Greg Stein [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 06, 2000 1:32 PM
>
> On Tue, Dec 05, 2000 at 03:38:45PM -0600, William A. Rowe, Jr. wrote:
> >...
> > Why do we add the additional complexity of a src/ directory within apr-util?
> > Can't we keep to the same simplicity as ap
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 06, 2000 1:10 PM
>
> trawick 00/12/06 11:09:48
>
> Modified:.configure.in
> Log:
> Fix the APR_HAVE_UNISTD_H symbol.
Thanks... I took my best guess the first time around,
but had no idea where I
On Wed, Dec 06, 2000 at 01:51:59PM -0600, William A. Rowe, Jr. wrote:
> > From: Greg Stein [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 06, 2000 1:32 PM
> >
> > On Tue, Dec 05, 2000 at 03:38:45PM -0600, William A. Rowe, Jr. wrote:
> > >...
> > > Why do we add the additional complexity o
> Two reasons:
>
> 1) we locate all the objects to add to the library using "find". it is
>easier to find them under "src/" rather than enumerating each source
>subdir. We can't use "." because that would pick up "test/".
This hasn't been an object in APR. I would prefer to enumerate th
> > 1) we locate all the objects to add to the library using "find". it is
> >easier to find them under "src/" rather than enumerating each source
> >subdir. We can't use "." because that would pick up "test/".
> >
> > 2) to keep the top-level cleaner. we have eight groups of functionalit
> +/* ### why do we have this, in addition to apr_make_sub_pool? */
> +apr_status_t apr_create_pool(apr_pool_t **newcont, apr_pool_t *cont)
We have create_pool because make_sub_pool is an incorrect name, it doesn't
make a sub_pool, it makes a pool. Add to that that we have to wrap
informatio
On Wed, Dec 06, 2000 at 12:30:33PM -0800, [EMAIL PROTECTED] wrote:
>
> > Two reasons:
> >
> > 1) we locate all the objects to add to the library using "find". it is
> >easier to find them under "src/" rather than enumerating each source
> >subdir. We can't use "." because that would pick
27 matches
Mail list logo
