apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: [PROPOSAL] Create apr-build repository
Date Fri, 13 Sep 2002 18:19:25 GMT
OK, but let's assume that apr is needed for these. I mean they are based on
apr (apr as in the original plain old boring apr library) right? Then I
guess what I don't understand is why we don't simply have the packages use a
script that tells them the location and then just use them...

The script is built by apr and installed, then either used from an install
or from the apr dir if we're in a cvs type environment...

Don't really think adding yet another cvs repository is going to cure the
basic problem you've been outlining, just add yet another place for it to
all go bang.


----- Original Message -----
From: "Aaron Bannert" <aaron@clove.org>
To: "APR Development List" <dev@apr.apache.org>
Sent: Friday, September 13, 2002 7:09 PM
Subject: Re: [PROPOSAL] Create apr-build repository

> On Fri, Sep 13, 2002 at 06:44:19PM +0100, David Reid wrote:
> > Not sure I like this. Shouldn't the other project just use the apr files
> > rather than copying their own versions?
> >
> > More context please...
> There's a code-redundancy problem that is sortof being caused by a
> build dependency problem.
> For example, flood uses some of the .m4 macros from APR's source
> directory. Since we don't want to go looking for those things in our
> buildconf script, we just stick them in flood's CVS and then include
> them in our configure.in file. This causes code duplication and forks
> our version from any updates to the real APR version.
> Ideally this apr-build package would simply install the .m4 and .in
> files in some directory, and provide a apr-build-config script that
> can be optionally called to discover where those .m4 and .in files were
> actually installed. That way it could be called straight from buildconf
> to find the m4 files, copy them to the right place, and then flood's
> configure is happy w/o having to maintain our own macro files.
> There are still a couple of gray spots in that scenario, in my mind,
> that need to be worked out, but this is the direction I'm looking.
> An alternative solution would be to have APR simply install those macro
> files somewhere so other projects could use them...
> -aaron

View raw message