Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 13 Sep 2002 11:09:18 -0700
From: Aaron Bannert <aaron@clove.org>
To: APR Development List <dev@apr.apache.org>
Subject: Re: [PROPOSAL] Create apr-build repository
Message-ID: <20020913180918.GT2528@clove.org>
Mail-Followup-To: Aaron Bannert <aaron@clove.org>,
	APR Development List <dev@apr.apache.org>
References: <20020913173631.GT1555@apache.org>
 <00f501c25b4d$307c0a00$7300a8c0@MITHRIL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00f501c25b4d$307c0a00$7300a8c0@MITHRIL>
User-Agent: Mutt/1.4i

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