You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Stein <gs...@lyra.org> on 2000/11/29 02:31:57 UTC
new APR package
Okay... we seem to have some general agreement to make a "non-core" APR
package that contains the "purely portable" items. With that in mind, here
are my rough ideas/notes on this:
*) create a new CVS module: /home/cvs/aprutil
[ other suggested names? aprkitchensink? :-) ]
[ I'll refer to it as APRUTIL for this message's purposes... ]
*) populate with a simple autoconf system that merely asks where APR headers
are. Since APRUTIL relies on APR for all portability items, and it
doesn't really have any options, it should not require a complicated
autoconf. Oh... if apu_dbm moves there, then it has a DBM selection
switch; that could just be shifted from Apache's autoconf.
[ hmm. presuming XML tools go in here, then some autoconf magic to point
at an installed Expat; note: this would be an opportune time to drop
expat-lite and just use the new Expat 1.95 package ]
*) I propose that it contains a number of packages/subsystems from APR and
Apache. The Apache portions are listed in:
http://www.apache.org/websrc/viewcvs.cgi/apache-2.0/src/lib/aputil/README
The APR portions would be MD5. *maybe* arrays and tables. (hashes must
stay because of their use in pools; pools stay because APR uses them)
[ what other pieces of APR are portable? (when built on APR) ]
*) each of the functional groups go into subdirs. overall package could look
like:
aprutil/
build/ build tools
docs/
include/
src/
buckets/ Apache bucket system
crypto/ cryptographic hashing/tools (MD5, SHA1, etc)
dbm/ DBM covers
encoding/ base64 encoding
hooks/ loosely-coupled, typesafe hooks
uri/ URI parsing/management
xml/ XML tools (ap_xml, plus some SVN stuff)
??? what else
test/
*) we'd use autoconf for config, and libtool for shared lib building.
automake is a maybe.
*) APRUTIL committers == APR committers. managed by the APR PMC.
I think that's all that I've got. Thoughts? Comments?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: new APR package
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
> On Wed, Nov 29, 2000 at 02:59:12AM +0100, Branko Cibej wrote:
>
>> Greg Stein wrote:
>>
>>> I think that's all that I've got. Thoughts? Comments?
>>
>> Maybe tweak APR scrpits so that they automagically find, configure and
>> build APRUTIL if somebody happens to unpack it (or checkout) in the APR
>> top-level directory? Then those users of APR that need APRUTIL too will
>> only have to deal with a single package (but would still link two
>> libraries, of course).
>
>
> The dependency goes the other way: APRUTIL depends upon APR. APR will know
> nothing about APRUTIL.
>
> Now... your statement could be applied to APRUTIL: if APRUTIL finds APR
> unpacked inside it, then it would do the right magic.
> [ much like SVN does sub-config on APR and Neon which are unpacked inside of
> its directory (altho the SVN case requires the subpackages) ]
Whatever. When I wrote that I was thinking of GCC, whose top-level
makefile will configure any marginally well-behaved package that happens
to be dropped in. But I realise now that our case is a bit different.
> It also seems feasible to create a "super package" of APR and APRUTIL. I
> would even presume that if somebody builds an APR RPM, they would include
> both libraries in it.
That was the idea, yes.
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: new APR package
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 29, 2000 at 02:59:12AM +0100, Branko Cibej wrote:
> Greg Stein wrote:
>
> > I think that's all that I've got. Thoughts? Comments?
>
> Maybe tweak APR scrpits so that they automagically find, configure and
> build APRUTIL if somebody happens to unpack it (or checkout) in the APR
> top-level directory? Then those users of APR that need APRUTIL too will
> only have to deal with a single package (but would still link two
> libraries, of course).
The dependency goes the other way: APRUTIL depends upon APR. APR will know
nothing about APRUTIL.
Now... your statement could be applied to APRUTIL: if APRUTIL finds APR
unpacked inside it, then it would do the right magic.
[ much like SVN does sub-config on APR and Neon which are unpacked inside of
its directory (altho the SVN case requires the subpackages) ]
It also seems feasible to create a "super package" of APR and APRUTIL. I
would even presume that if somebody builds an APR RPM, they would include
both libraries in it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: new APR package
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
> I think that's all that I've got. Thoughts? Comments?
Maybe tweak APR scrpits so that they automagically find, configure and
build APRUTIL if somebody happens to unpack it (or checkout) in the APR
top-level directory? Then those users of APR that need APRUTIL too will
only have to deal with a single package (but would still link two
libraries, of course).
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: new APR package
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 28, 2000 at 06:45:03PM -0800, Brian Behlendorf wrote:
> On Tue, 28 Nov 2000, Greg Stein wrote:
> > Okay... we seem to have some general agreement to make a "non-core" APR
> > package that contains the "purely portable" items. With that in mind, here
> > are my rough ideas/notes on this:
> >
> > *) create a new CVS module: /home/cvs/aprutil
> > [ other suggested names? aprkitchensink? :-) ]
> > [ I'll refer to it as APRUTIL for this message's purposes... ]
>
> Would /home/cvs/apr-util be OK? That would save me some structural foo
> with mailing lists & all.
This will be fine, but let's hold off for a day or two. There hasn't been
any real discussion (based on my email proposal).
But one point to make: the CVS module will be "apr-FOO" (where FOO is util,
or some other name we decide upon).
> Is a separate dev & cvs list desired?
Nope.
IMO, the distinction is based on semantics and organizational needs. The
same set of people will be developing/maintaining it.
[ well, I could see that if we shift a bunch of Apache functionality into
APRUTIL, then we might see more Apache folks want commit access to work on
the stuff. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: new APR package
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 29, 2000 at 07:59:41AM -0800, rbb@covalent.net wrote:
> On Tue, 28 Nov 2000, Brian Behlendorf wrote:
>
> > On Tue, 28 Nov 2000, Greg Stein wrote:
> > > Okay... we seem to have some general agreement to make a "non-core" APR
> > > package that contains the "purely portable" items. With that in mind, here
> > > are my rough ideas/notes on this:
> > >
> > > *) create a new CVS module: /home/cvs/aprutil
> > > [ other suggested names? aprkitchensink? :-) ]
> > > [ I'll refer to it as APRUTIL for this message's purposes... ]
> >
> > Would /home/cvs/apr-util be OK? That would save me some structural foo
> > with mailing lists & all.
> >
> > Is a separate dev & cvs list desired?
>
> I was going to suggest /home/cvs/apr/util, in other words, make this a sub
> project of APR for now, and split it to it's own CVS repository later.
>
> Regardless, the dev and cvs mailing lists should be APR's, this should not
> have it's own mailing lists yet. Think of this as an APR sister-project.
Let's make it a true sister project, rather than trying to split it later.
If we defer the split, then we just end up with a large Attic.
If we're starting from scratch, then the old difference between a new sister
CVS module and a sub-project is that the former is where we want to be
already.
But I definitely agree re: mailing lists.
===> Does anybody have any issue with having Brian spin up a new CVS module
named apr-util?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: new APR package
Posted by rb...@covalent.net.
On Tue, 28 Nov 2000, Brian Behlendorf wrote:
> On Tue, 28 Nov 2000, Greg Stein wrote:
> > Okay... we seem to have some general agreement to make a "non-core" APR
> > package that contains the "purely portable" items. With that in mind, here
> > are my rough ideas/notes on this:
> >
> > *) create a new CVS module: /home/cvs/aprutil
> > [ other suggested names? aprkitchensink? :-) ]
> > [ I'll refer to it as APRUTIL for this message's purposes... ]
>
> Would /home/cvs/apr-util be OK? That would save me some structural foo
> with mailing lists & all.
>
> Is a separate dev & cvs list desired?
I was going to suggest /home/cvs/apr/util, in other words, make this a sub
project of APR for now, and split it to it's own CVS repository later.
Regardless, the dev and cvs mailing lists should be APR's, this should not
have it's own mailing lists yet. Think of this as an APR sister-project.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: new APR package
Posted by Brian Behlendorf <br...@collab.net>.
On Tue, 28 Nov 2000, Greg Stein wrote:
> Okay... we seem to have some general agreement to make a "non-core" APR
> package that contains the "purely portable" items. With that in mind, here
> are my rough ideas/notes on this:
>
> *) create a new CVS module: /home/cvs/aprutil
> [ other suggested names? aprkitchensink? :-) ]
> [ I'll refer to it as APRUTIL for this message's purposes... ]
Would /home/cvs/apr-util be OK? That would save me some structural foo
with mailing lists & all.
Is a separate dev & cvs list desired?
Brian