Yes, we have libaprutil.* on Unix (.a, .so, .la)
Cheers,
-g
On Tue, Dec 12, 2000 at 05:48:47PM -0600, William A. Rowe, Jr. wrote:
> libaprutil.so? This will become libaprutil.dll then. Didn't matter,
> since the entire scope of the system was being overhauled, including
> library names. As lon
Nack...
my cvs says 'foo not found ... skipping'
Bill
> -Original Message-
> From: Greg Stein [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 12, 2000 3:54 PM
> To: dev@apr.apache.org
> Subject: Re: cvs commit: apr-util/include apu_private.h.in
> apu_private.hw
>
>
> On Tue, Dec
libaprutil.so? This will become libaprutil.dll then. Didn't matter,
since the entire scope of the system was being overhauled, including
library names. As long as they have a lib prefix on unix, they need
to share that prefix on win32.
Thanks for the observation, though!
Bill
> -Original
Is it normal to put a dash into libraries, DLLs? I've never seen one.
We certainly don't include it in the Unix builds. The dash in "apr-util" is
an aspect of the setup on locus, rather than a specific intention.
Cheers,
-g
On Tue, Dec 12, 2000 at 05:55:32PM -, [EMAIL PROTECTED] wrote:
> wro
On Tue, Dec 12, 2000 at 05:11:02PM -, [EMAIL PROTECTED] wrote:
> wrowe 00/12/12 09:11:01
>
> Removed: include apu_private.h.in apu_private.hw
> Log:
> These files belong in the Attic ... this has messed up testing the builds
> since folks still had them on their machines
Cool. Thx!
-g
On Tue, Dec 12, 2000 at 03:12:41PM -, [EMAIL PROTECTED] wrote:
> trawick 00/12/12 07:12:40
>
> Modified:.Makefile.in
> Log:
> Get rid of "-maxdepth 0" on the find invocation. This breaks on Tru64
> and FreeBSD, and I can't tell that it helps anyway.
>
--- Greg Stein <[EMAIL PROTECTED]> wrote:
> This patch is much better, and I've gone ahead and applied it. However,
> you're discarding the return values from ap_bucket_read(). Those should be
> returned. The prototype ought to look like:
>
> apr_status_t ap_brigade_partition(ap_bucket_brigade
> >SOURCE=.\src\buckets\ap_buckets_socket.c
> > -# End Source File
> > -# Begin Source File
> > -
> > -SOURCE=.\src\buckets\ap_buckets_util.c
> ># End Source File
> ># End Group
> ># Begin Group "crypto"
>
> Why did we drop ap_buckets_util.c? All your other changes made s
Just looked at the tree... nevermind
> -Original Message-
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 12, 2000 10:20 AM
> To: 'dev@apr.apache.org'; '[EMAIL PROTECTED]'
> Subject: RE: cvs commit: apr-util aprutil.dsp
>
>
> Is there a reason for part of
Is there a reason for part of the last change?
> ake 00/12/12 07:54:31
>
> Modified:.Makefile.win
>.aprutil.dsp
> Log:
> Fix Windows build
>
> Index: aprutil.dsp
> @@ -189,10 +179,6 @@
># Begin Source File
>
>SOURCE=.\src\bucket
[EMAIL PROTECTED] writes:
> gstein 00/12/12 03:05:33
>
> Modified:.Makefile.in
> Log:
> auto-rebuild the exports file when a header changes
>
> Revision ChangesPath
> 1.6 +14 -3 apr-util/Makefile.in
>
> Index: Makefile.in
> =
On Mon, Dec 11, 2000 at 10:15:01PM -0800, Cliff Woolley wrote:
> --- Cliff Woolley <[EMAIL PROTECTED]> wrote:
> > ...
> > +if (point < len) {
> > +if (ap_bucket_split(e, point) == APR_SUCCESS)
> > +return AP_BUCKET_NEXT(e);
> > +else
>
The include path points to the private area first, but you'll still want to
remove the old files (apr-util/include/apu_*). You'll get a reminder at your
next "cvs update" because the .cvsignore was moved into the private area (so
those files are now "spurious").
Cheers,
-g
On Tue, Dec 12, 2000 at
--- Cliff Woolley <[EMAIL PROTECTED]> wrote:
> ...
> +if (point < len) {
> +if (ap_bucket_split(e, point) == APR_SUCCESS)
> +return AP_BUCKET_NEXT(e);
> +else
> +return NULL;
> +}
> +else if
Okay, here is the updated patch. I've dumped ap_brigade_split_offset() in
favor of
ap_brigade_partition() as suggested by Greg.
Note as I mentioned in my previous email that all you have to do to simulate the
behavior of _split_offset() is effectively the following, though in reality
you'd
wan
--- Greg Stein <[EMAIL PROTECTED]> wrote:
> The reason that I asked for a bucket return value was so that we could split
> the brigade at point P3/4, and get a pointer to B4 back (the start of the
> copy). We split at point P6/7 and get P7 back (the bucket after the last to
> copy).
Oooohhh y
Sorry... my post may have been misleading. The split wasn't supposed to do
any copying. Just do a single split and return a ptr to the bucket after the
split point. On top of *that*, we built the functionality below.
[ e.g. the functionality below is what the byterange filter does ]
Doing a bucke
On Sat, Dec 09, 2000 at 09:35:26AM -0800, [EMAIL PROTECTED] wrote:
>...
>... [copying returned datums] ...
>...
> Actually, that's not true. I have added SDBM support to a couple modules
> recently,
Cool! Well, I'm doubly glad, then, that we will directly export SDBM from
APRUTIL (in addition to
On Sat, Dec 09, 2000 at 08:46:17AM -0800, [EMAIL PROTECTED] wrote:
> > > then split_any() could just tell it how much to read, and this wouldn't
> > > be as much
> > > of an issue. Alternately, split_any() could just keep track of how much
> > > was read
> > > and loop through an arbitrary numbe
19 matches
Mail list logo
