On Nov 23, 2007 2:37 AM, Joe Orton [EMAIL PROTECTED] wrote:
** Key proposal: one tree, multiple libraries
+1.
** Second (more controversial/radical?) proposal:
Reduce the consolidated libapr library size by chucking out everything
from apr-util which has been around for N years and is not
On Fri, 2007-11-23 at 10:22 -0600, William A. Rowe, Jr. wrote:
are we looking at a 1.3 iteration before we
make such radical changes as 2.0? If so, when? I'd love to see 1.3
come together over the next month or two for those who don't want to
wait on/depend upon such a major release bump.
I
On Nov 29, 2007 12:48 PM, Bojan Smojver [EMAIL PROTECTED] wrote:
On Fri, 2007-11-23 at 10:22 -0600, William A. Rowe, Jr. wrote:
are we looking at a 1.3 iteration before we
make such radical changes as 2.0? If so, when? I'd love to see 1.3
come together over the next month or two for those
2007/11/24, Bojan Smojver [EMAIL PROTECTED]:
I think the only criteria here should be that it has to have no users.
But then again, how does one figure that one out?
If a feature is broken for a long time and nobody complains.
Marc Mongenet
* Joe Orton
| apr-config is extended to expose a new interface to select which
| sub-libraries an app wishes to link against.
Pimping my own tool here, but could we make pkg-config the preferred
interface and deprecate apr-config? pkg-config is increasingly
becoming the standard way of
On Mon, November 26, 2007 12:29 pm, Tollef Fog Heen wrote:
Pimping my own tool here, but could we make pkg-config the preferred
interface and deprecate apr-config? pkg-config is increasingly
becoming the standard way of providing build time
information.
Using standard mechanisms in place of
On Nov 23, 2007, at 5:37 AM, Joe Orton wrote:
** Key proposal: one tree, multiple libraries
Justin has long argued that there is no point in having apr and apr-
util
as separate trees since everyone uses both or neither, and I agree.
+1
Joe Orton [EMAIL PROTECTED] said:
** Key proposal: one tree, multiple libraries
Justin has long argued that there is no point in having apr and apr-util
as separate trees since everyone uses both or neither, and I agree. The
fact that every downstream application picks up depdendencies on
On Nov 26, 2007 2:55 PM, Ryan Phillips [EMAIL PROTECTED] wrote:
Joe Orton [EMAIL PROTECTED] said:
** Key proposal: one tree, multiple libraries
Justin has long argued that there is no point in having apr and apr-util
as separate trees since everyone uses both or neither, and I agree. The
Ryan Phillips wrote:
I agree APR and APR-util should be combined into one, but I hate the notion
of chunking the library into multiple parts. If a developer wants to
disable a feature, then a simple --without-xml or --without-dbm should
suffice.
This works if you have built the library from
Ryan Phillips wrote:
I agree APR and APR-util should be combined into one, but I hate the notion
of chunking the library into multiple parts. If a developer wants to
disable a feature, then a simple --without-xml or --without-dbm should
suffice.
Not really - we need to all play against APR
On Mon, 2007-11-26 at 11:55 -0800, Ryan Phillips wrote:
What is the benefit in chunking a library?
Lower memory footprint, among other things.
--
Bojan
On Mon, Nov 26, 2007 at 11:29:34AM +0100, Tollef Fog Heen wrote:
* Joe Orton
| apr-config is extended to expose a new interface to select which
| sub-libraries an app wishes to link against.
Pimping my own tool here, but could we make pkg-config the preferred
interface and deprecate
Joe Orton wrote:
** Key proposal: one tree, multiple libraries
Justin has long argued that there is no point in having apr and apr-util
as separate trees since everyone uses both or neither, and I agree. The
fact that every downstream application picks up depdendencies on half
the
Joe Orton wrote:
On Fri, Nov 23, 2007 at 10:22:43AM -0600, William Rowe wrote:
DBM/DBD are on the right-track. But not yet on unix. I hope to have the
working dynamic build of these db providers working on unix by end of mo,
because it's critical to one of my own projects.
Can you explain
On Fri, November 23, 2007 12:37 pm, Joe Orton wrote:
Justin has long argued that there is no point in having apr and apr-util
as separate trees since everyone uses both or neither, and I agree.
I have used APR in some commercial projects, and these have used apr
exclusively, and not apr-util,
** Key proposal: one tree, multiple libraries
Justin has long argued that there is no point in having apr and apr-util
as separate trees since everyone uses both or neither, and I agree. The
fact that every downstream application picks up depdendencies on half
the third-party libraries in
On Fri, Nov 23, 2007 at 10:22:43AM -0600, William Rowe wrote:
DBM/DBD are on the right-track. But not yet on unix. I hope to have the
working dynamic build of these db providers working on unix by end of mo,
because it's critical to one of my own projects.
Can you explain what is not on the
On Fri, Nov 23, 2007 at 10:55:14AM -0600, William Rowe wrote:
Joe Orton wrote:
If LDAP/expat/ssl can be similarly refactored, and only dynaload once the
specific apr object is initialized,
Can you be more specific about what you are proposing here? Only
dynaload what exactly? The actual
Joe Orton wrote:
This describes the way the DBD/DSO code works now. This type of
arrangement is perfect for code which has vtable-like abstractions on
top of the third-party library, as DBD does, but doesn't really work for
anything else.
yes - requires abstraction but doesn't necessarily
20 matches
Mail list logo
