Large project architecture and similarities to Svn

Hello,

I'm looking for perspectives on how to manage the source
for these external 
libraries.  Details below.


Details:

I'm an experienced Subversion admin and user.  I am also
managing a large 
software endeavor that is about to be introduced as
open-source project.  I 
hope it's ok to post the developers list, for my questions
seem better 
directed towards those managing the development project (I
think).

I see several similarities between my project and
Subversion, namely that 
we use several external libraries much the same way that
Subversion 
leverages apr and neon (and possibly others).

I'm looking for perspectives on how to manage the source
for these external 
libraries.  I see in the current trunk 
(<http://svn
.collab.net/repos/svn/trunk/>) that there is no
'apr' nor 
'neon' directory as documented per 
<http://subversion.tigris.org/hacking.html#directo
ry-layout>.  Are these 
vendor-external source sets still managed by Subversion? 
Last time I build 
svn (from a 1.3.0 tarball) I recall the src tarball
including apr and neon 
software.

Right now I'm weigh my project's options for managing this
external 
source.  Our current build farm/development machines current
checkout 
header files and binary libraries (both static and dynamic)
from a 
controlled repo in order to build the application binaries
for our 
stuff.  However, I think we are reaching our limit for this
applicability, 
in that some external library binaries may be too
platform/environment 
dependent (eg, Debian3.1-stable boost 1.32.0 libs built
under an older 
version of gcc/g++ don't work well on Debian3.1-testing,
etc)...and thus 
there are benefits to building everything from source
(separate from a 
package-file/.rpm/.deb install which requires the right libs
be 
installed/available).

The question is...how to manage this?  I figure the source
for these 
projects is best distributed in a big tarball like
Subversion does?  Or 
not?  What about the repo management--should said source be
in there in the 
apparently-classic 'external vendor' management?  It sure
would help in the 
event we want to edit said source.

For what it's worth, our current list of external
mechanisms/libraries are 
as follows:

ACE (Adaptive Communication Environment)
Boost C++ libraries (3-5 libs thus far, probably more over
time)
BZip compression
OpenSSL cryptogorphy and networking
libpqxx: PostgreSQL C++ interface
Xerces-c XML parser
Ptypes network interface (optional)
SQLite database libraries (optional)


I can provide more info as needed.  I'm in the early stages
of researching 
this stuff, so please pardon any ignorant questions.  I'm
probably going to 
go browse around the Apache development area next to see
what they do and 
if they face similar challenges.

-Matt


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 3/30/06, Matt England <menglandmengland.net> wrote:

> I'm looking for perspectives on how to manage the
source for these external
> libraries.  I see in the current trunk
> (<http://svn
.collab.net/repos/svn/trunk/>) that there is no
'apr' nor
> 'neon' directory as documented per
> <http://subversion.tigris.org/hacking.html#directo
ry-layout>.  Are these
> vendor-external source sets still managed by
Subversion?  Last time I build
> svn (from a 1.3.0 tarball) I recall the src tarball
including apr and neon
> software.

We include those in our release tarballs as a courtesy to
users,
they're not stored in our repository, but if the
directories are
present the build system will take advantage of them.  In
general, I
don't think most developers actually put apr/apr-util/neon
there for
development purposes, personally I tend to install versions
into a
special --prefix and use that for day to day development.

(This is different on windows of course, where you basically
have to
have them as part of your source tree in a location dictated
by the
build system.)

-garrett

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org