[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: APR-UTIL package build

From: David Summers <david_at_summersoft.fay.ar.us>
Date: 2002-02-02 03:57:25 CET

Yes, I believe that is possible, if I understand what you are saying.

I'm working on "exporting" it from apache right now as apache already has
to have them both any way. I could either build an apr and apr-util
package from the apache RPM spec file or if I could figure out how to
build APR-UTIL from the APR package then that would be another option.

I tried the second method already but no luck (I probably just haven't
figure it out yet). Since the first method almost builds what I want
anyway, I'm trying the first method right now.

Thanks for the clues.

    - David

On Fri, 1 Feb 2002, Greg Stein wrote:

> On Fri, Feb 01, 2002 at 08:10:42PM -0600, David Summers wrote:
> >...
> > Now as of last night, the RPM build is broken because of the APR-UTIL
> > requirement and I'm just trying to figure out the best way to get
> > everything to compile and link. I'm wondering if it might be possible to
> > export the APR-UTIL development environment as a part of the apache-devel
> > package because it already has both APR and APR-UTIL, or wondering if it
> > is possible to build a package that combines the APR and APR-UTIL
> > development environments. If I could export APR and APR-UTIL from apache
> > then that would mean one less package required for subversion.
> >
> > I was able to build APR as a separate package, but I've not figured out
> > how to do that with APR-UTIL.
> >
> > Just trying to examine all the options. I could build it in to subversion
> > if I have to but that seems icky from a package management point of view,
> > unless I have no other choice.
> >
> > Anyone have any ideas?
>
> APRUTIL should definitely be a separate package -- that is the intent.
>
> The question then becomes, can it?
>
> Since SVN has just become one of the first few users of a APRUTIL as a
> distinct entity, then it is fair to say that we have a bit of work to get
> things straightened out entirely. While APRUTIL has always been intended as
> a separate package, and work was done towards that goal... I don't know how
> much testing of that goal was performed :-)
>
> I believe Justin uses APRUTIL as part of the "flood" tool, so it definitely
> works to an extent.
>
> In particular, I know there are some issues with aprutil exporting where it
> found Expat. There are the bigger issues of its reliance on APR for its
> build system. That then falls back to APR and it needing to install that
> build system for others to use.
>
> In particular, I plan to make APR install an additional directory:
>
> $prefix/lib/aprX.Y/
>
> In there would be the rules.mk, libtool script, etc, which APRUTIL depends
> upon (and other apps, such as httpd, could as well).
>
> In turn, this means your RPM would also want to install that directory and
> publish those files.
>
> I'm hoping to get to this *late* tonite. Was gonna last night, but my time
> disappeared (sigh).
>
> One of your short-term problems is what to do with the RPMs. Unfortunately,
> you cannot build APRUTIL inside of Subversion, and leave APR outside. There
> is a nasty dependency in APRUTIL that depends upon APR being located at
> ../apr/. If SVN finds APRUTIL "outside", then it simply assumes that it was
> able to compile/build itself *somehow* -- it simply isn't SVN's problem.
>
> So... if anything, your short term solution would be to build two binary
> packages from the same source package. Have APR and APRUTIL in the source
> package, located (properly) relative to each other. Produce two binary
> packages from that. (which I believe is possible?)
>
> Cheers,
> -g
>
>

-- 
David Wayne Summers          "Linux: Because reboots are for upgrades!"
david_at_summersoft.fay.ar.us   PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint =  C0 E0 4F 50 DD A9 B6 2B  60 A1 31 7E D2 28 6D A8 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:03 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.