Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@httpd.apache.org
Message-Id: <5.2.0.9.2.20031121150748.0213e0c0@pop3.rowe-clan.net>
Date: Fri, 21 Nov 2003 15:50:07 -0600
To: test-dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@apache.org>
Subject: Re: problems compiling flood, REALLY Flood out of sync with
  APR, ALSO note that apr_poll() no longer in APR
In-Reply-To: <Pine.GSO.4.05.10311211436030.18108-100000@photon.poly.edu>
References: <B2CBEAA41E707D4888BC0483D893323CF560B4@x.sfo.covalent.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:58 PM 11/21/2003, Norman Tuttle wrote:
>Apparently, Flood development cannot keep up with the APR development.
>This is a problem because many of the Flood features working properly is
>dependent on the APR working properly (and continuing to work). It is
>essential for those working with Flood to be able to download the latest
>APR and other Apache dependencies it has in order to benefit from the many
>bug fixes, etc., which are continuing to become available. 

Whoha!  The *latest APR* ... so you suggest that APR's dev branch, 1.0,
should consistently build and compile 24/7, immediately useable to flood?

<snicker>

I absolutely agree that flood aught to track the latest progress, but tracking
does imply coming 'after' the changes in apr.  That change was less than
a day old, so I think you are overstating things here.

APR_1_0 does *not* exist yet.  It will exist soonish.  We are dropping alot
of left-over cruft that came from evolving a library that hadn't existed before
APR 0.9 was begun.

Flood should either 1) rely on the stable branch (APR_0_9_BRANCH) or 
2) recommend a released tarball (0.9.4 or some such).

But I'm not discouraging authors from tracking the dev branch (HEAD), that
will soon become APR 1.0!  It's great you found the dependency (apparently
a permanent one) on apr_poll.  Obviously the APR project needs folks like
our test-dev'ers to tell us what you need, so the project continues to be
relevant and useful.

All of this is to say "Thanks for putting your faith in APR, and please pardon
our dust when you attempt to track cvs head!"

>Perhaps the Apache folks ought to continue to support the previous 
>interfaces while making new methods available so that projects which 
>have dependencies on the APR and its other subprojects can continue 
>to compile.

1) we aren't Apache (server) folks when wearing our APR hats :-)
2) the old interfaces are gone, nada, goodbye.

On every major version bump (0.x -> 1.x, 1.x -> 2.x etc) we will be dumping
all deprecated interfaces.  These are actually well documented in doxygen
(@deprecated tags) so that everyone knows what is going, and what had
replaced it.  In these cases flood had 6+ months to change over ;-)

The authors all want apr to be lightweight and bug free.  Extra, lingering,
deprecated interfaces are just one more bit of baggage that can hamper
our maintenance and end-users.  Yes, it's inconvenient, but you can always
continue to use an older, previous version.  APR's installed libraries are
versioned, so if you linked to libapr-0.so the big cleanup in apr 1.0 should
not get in your way.

(This includes win32.  While libapr.dll is 0.x, libapr-1.dll versioned names
will be used moving forwards.)

>Your compile will probably also fail, however, when it encounters
>apr_poll(), which they apparently have also taken out of the APR.
>I'm not sure what the replacement for that is; maybe somebody on this list
>or on the APR list can enlighten us on what changes are happening there.

Yup - consensus suggests this should not have been removed.  And therein
is the value of a handful of brave test-dev'ers living life on the bleeding edge :)

Bill