You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Matt England <me...@mengland.net> on 2006/03/30 19:57:22 UTC
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#directory-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-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Large project architecture and similarities to Svn
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/1/06, Matt England <me...@mengland.net> wrote:
> At 3/30/2006 02:39 PM, Garrett Rooney wrote:
> >On 3/30/06, Matt England <me...@mengland.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#directory-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.
>
> eg, into /usr/lib & /usr/include or /usr/local/lib &/usr/local/include for
> the apr and neon stuff?
Personally, sometimes I install them into system locations, sometimes
I install into some random directory in my home directory. In my home
directory tends to be more common, as I tend to install multiple
different versions of APR, partly because I need to test svn with
them, partly because I'm also an APR developer.
> >(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.)
>
> ...except for MinGW/MSYS configurations?
I imagine those would work more like a unix install, although I
haven't actually done that sort of build personally, so I'm not sure.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Large project architecture and similarities to Svn
Posted by Matt England <me...@mengland.net>.
At 3/30/2006 02:39 PM, Garrett Rooney wrote:
>On 3/30/06, Matt England <me...@mengland.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#directory-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.
eg, into /usr/lib & /usr/include or /usr/local/lib &/usr/local/include for
the apr and neon stuff?
>(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.)
...except for MinGW/MSYS configurations?
Again, if my questions are out of place, please let me know.
-Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Large project architecture and similarities to Svn
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 3/30/06, Matt England <me...@mengland.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#directory-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-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org