Re: [reSIProcate] major directory reorg
Hi all,
Take a look at
https://scm.sipfoundry.org/rep/resiprocate/branches/b-directory-reorg
when you get a chance. It should be all compiling using default build
system. See what you think.
Major things that happened in the reorg (so far):
* eliminated sip subdirectory under main
* moved dum to toplevel parallel to resiprocate
* renamed/moved os from resiprocate/os to toplevel rutil
* moved all contents classes to resiprocate/contents
* moved resiprocate/dns to toplevel rdns
* moved resiprocate/external to rdns/external
* adjusted all Makefile and #include directives accordingly
On 6/14/05, Robert Sparks <rjsparks@xxxxxxxxxxx> wrote:
> inline
> On Jun 13, 2005, at 11:29 PM, Jay Hogg wrote:
>
> > I really didn't mean to cause this much upheaveal in the plan...
> >
> > I also like Proposal 1 and keeping "applications" in seperate
> > repositories
> > will, I believe, keep some sanity in the library builds and
> > distribution.
> >
> > I have another question that I hope is not quite as loaded as the prior
> > group. Has consideration been given in the build and distribution
> > layouts
> > for the handling of "headers that include headers"- DUM including Resip
> > and OS (now in resip?) specifically?
> >
> > In my version of "ideal" when I am developing project X against
> > Resip/DUM
> > I would like to point my includes to /usr/local/resip -OR- to
> > ~/projects/resip/trunk/build
> > and have them build correctly. This works today because of the
> > resip/os/dum
> > layout but how will it work now in autotools vs "installed"? Think
> > about it in
> > terms of both the "applications/tools" that are built in the library
> > repository
> > and those on the outside.
> >
> > -I ${top_srcdir}/build/resiprocate:${top_srcdir}/build/dum
> > works but are the includes going to be flattened out when installed or
> > put in nested directories?
>
> So we're looking at taking this in steps, and at each step
> there will still be an explicit mention of part of the project in any
> include path.
> That is, you will still do something like #include
> "resiprocate/SipStack.hxx"
> and not #include "SipStack.hxx" if that's what you meant by flattening.
>
> The first step will be to try reorganizing the major groups along the
> lines
> of Jason's proposal 1. Then inside a directory like dum, we are
> thinking of
> pushing things towards separated src and includes, with the includes
> split
> between those that are meant for an application to use (what would get
> installed) and those that are a part of the internal implementation.
>
> While we seem to have some consensus around the general ideas (I'm sure
> there are some other opinions that haven't had a chance to be
> expressed),
> keep in mind that this branch/thread represents an _experiment_.
> We might stop, reboot, and try something completely different before we
> are through.
>
>
>
> >
> > What other dependencies are we going to run into with something like
> > ares being pulled in by headers vs cpp? Remember that you can't use
> > any of
> > the autotools flags in the headers because the application being
> > DEVELOPED
> > may be autotools and the flags are set.
>
> No kidding. This is something that's biting me a lot in other projects,
> and I'm
> looking very closely at what we can do as we move forward to make it not
> bite with this one. We're in better shape than most - we've had
> "distribute
> config.h" disease creep in in only two places, and I think those will
> be easy
> to clean up.
>
> >
> > I wish I had more time to provide possible solutions because I ran into
> > these
> > (and HAVE_CONFIG_H) in headers when I first started using resip/dum
> > outside
> > the resip directory structure in an autotools projects but you're
> > moving
> > faster
> > than me at the moment on the reorg so I figured I had to get my
> > comments in.
>
> Well, we're going to pause now and divert our attention to improving
> the documentation
> for the project. We've got a big crowd meeting in Dallas for the next
> three days to hammer
> on that.
>
> >
> > Jay
> >
> >
> > Robert Sparks wrote:
> >
> >> After even _more_ discussion (I first participated in this today), the
> >> thinking is to follow proposal 1 _except_ that we'll keep MSRP in its
> >> own subversion repository.
> >>
> >> We will continue to discuss whether it makes sense to put repro
> >> in its own repository.
> >>
> >> Keeping rutil inside the same repository as resiprocate and dum
> >> makes sense. (Though we might _release_ it in a separate tarball).
> >>
> >> I'm going to create a branch to start experimenting with this
> >> reorganization in.
> >>
> >> RjS
> >>
> >> On Jun 12, 2005, at 3:29 PM, Fischl jason wrote:
> >>
> >>> After much discussion in Dallas, here is take 2 on reorg plan. The
> >>> previous proposal had an issue where revision numbers could not be
> >>> common across the different projects. Here are two proposals that
> >>> address this. Mostly this involves directory restructuring and
> >>> importing msrp into the same subversion module as the other projects.
> >>>
> >>>
> >>> Proposal 1:
> >>> main/build
> >>> /autotools
> >>> /contrib
> >>> /resiprocate
> >>> /resiprocate/doc
> >>> /resiprocate/test
> >>> /dum
> >>> /dum/doc
> >>> /dum/test
> >>> /rutil
> >>> /rutil/doc
> >>> /rutil/test
> >>> /repro
> >>> /repro/doc
> >>> /repro/test
> >>> /msrp
> >>> /msrp/doc
> >>> /msrp/test
> >>> - this is relatively close to what we have now in that the source
> >>> files are in the first subdirectory. e.g. in main/resiprocate
> >>> - complaint is that the README file, doc and test directories are
> >>> hard
> >>> to find amongst the source files
> >>> - eliminates the "sip" directory
> >>>
> >>>
> >>> Proposal 2:
> >>> main/build
> >>> /autotools
> >>> /contrib
> >>> /resiprocate/src
> >>> /resiprocate/doc
> >>> /resiprocate/test
> >>> /dum
> >>> /dum/src
> >>> /dum/doc
> >>> /dum/test
> >>> /rutil
> >>> /rutil/src
> >>> /rutil/doc
> >>> /rutil/test
> >>> /repro
> >>> /repro/src
> >>> /repro/doc
> >>> /repro/test
> >>> /msrp
> >>> /msrp/src
> >>> /msrp/doc
> >>> /msrp/test
> >>> - also eliminates the sip subdirectory.
> >>> - requires third party applications to run make install to have
> >>> access
> >>> to project header files
> >>>
> >>> On 6/12/05, Jay Hogg <jay@xxxxxxxxxxxxxx> wrote:
> >>>
> >>>> Jason,
> >>>>
> >>>> While I welcome the reorg because I think it makes more
> >>>> sense I have a fundamental question. You specifically say
> >>>> 'different repositories' and is where my questions come
> >>>> from:
> >>>>
> >>>> - We now have to track commit versions across 5 repositories
> >>>> to know what is current?
> >>>>
> >>>> - Symlinks are easy when everything is in trunk and fully
> >>>> compatible. How is it going to be handled when RESIP
> >>>> branches and what is required by DUM (and friends) is now a
> >>>> branch in RESIP and "RESIP trunk" isn't compatible the DUM
> >>>> trunk or REPRO trunk?
> >>>>
> >>>> - Is this going to require that ALL new development work be
> >>>> done in a branch and merged at one time so "trunk" is stable
> >>>> through the entire lineage? If I want to work with "DUM
> >>>> unstable" I will checkout RESIP from the top-down then
> >>>> checkout "dum unstable" someplace to work on it?
> >>>>
> >>>> The reason I ask is where I work we've been migrating our
> >>>> CVS and Vss repositories to SVN for about 6 months. We split
> >>>> some things that "obviously needed to be split" and have had
> >>>> some versioning hell between a couple packages and
> >>>> supporting libraries. Part of it is communications and
> >>>> knowing what is happening but it is also hard to syncronize
> >>>> multiple groups with different objectives and deadlines.
> >>>>
> >>>> Just some thoughts...
> >>>>
> >>>> Jay
> >>>>
> >>>> ----- Original Message Follows -----
> >>>> From: Fischl jason <jason.fischl@xxxxxxxxx>
> >>>> To: resiprocate <resiprocate-devel@xxxxxxxxxxxxxxxxxxx>
> >>>> Subject: [reSIProcate] major directory reorg
> >>>> Date: Sat, 11 Jun 2005 14:22:05 -0700
> >>>>
> >>>>> While in Dallas we've discussed a major reorg of the
> >>>>> directory structure for resip/dum/repro/msrp. Here's the
> >>>>> plan:
> >>>>>
> >>>>> Current:
> >>>>>
> >>>>> resip:
> >>>>> main/sip/resiprocate
> >>>>> /resiprocate/os
> >>>>> /resiprocate/dum
> >>>>> /resiprocate/dum/doc
> >>>>> /resiprocate/dum/test
> >>>>> /resiprocate/test
> >>>>> /resiprocate/doc
> >>>>> /repro
> >>>>> /contrib
> >>>>>
> >>>>> msrp:
> >>>>> main/src
> >>>>> main/doc
> >>>>>
> >>>>> Proposed
> >>>>> Each of resip, rutil, repro, dum, contrib will be a
> >>>>> different repository. Here's roughly what the intermodule
> >>>>> dependency is. We'll use symbolic links (in svn) to
> >>>>> satisfy the intermodule dependencies. If you check out
> >>>>> repro, it will check out the appropriate dependent modules
> >>>>> through the sym links.
> >>>>>
> >>>>> repro
> >>>>> |
> >>>>>
> >>>>> |---------------|--------------------------|
> >>>>> dum contrib/db
> >>>>> contrib/pcre
> >>>>> |
> >>>>> resip
> >>>>> |
> >>>>> ----------------------------------
> >>>>> | |
> >>>>> contrib/ares rutil
> >>>>>
> >>>>> resip:
> >>>>> main/src/resiprocate
> >>>>> main/src/test
> >>>>> main/doc
> >>>>>
> >>>>> rutil: // resiprocate util
> >>>>> main/doc
> >>>>> main/src/rutil
> >>>>> main/src/test
> >>>>>
> >>>>> repro:
> >>>>> main/doc
> >>>>> main/src/repro
> >>>>> main/src/test
> >>>>>
> >>>>> dum:
> >>>>> main/doc
> >>>>> main/src/dum
> >>>>> main/src/test
> >>>>>
> >>>>> contrib:
> >>>>> main/contrib
> >>>>> main/contrib/ares
> >>>>> main/contrib/db
> >>>>> main/contrib/pcre
> >>>>> main/contrib/dtls
> >>>>> main/contrib/getopt
> >>>>>
> >>>>> Implications:
> >>>>> - break out common utilities into rutil as a separate
> >>>>> library. - Eliminates the os subdirectory -> will require
> >>>>> mods to apps - Moves dum to its own module instead of
> >>>>> subdir of resiprocate -> will require mods to apps
> >>>>> - symlinks are only supported in subversion >= 1.1
> >>>>> _______________________________________________
> >>>>> resiprocate-devel mailing list
> >>>>> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>>>>
> >>>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>>> _______________________________________________
> >>>> resiprocate-devel mailing list
> >>>> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>>>
> >>> _______________________________________________
> >>> resiprocate-devel mailing list
> >>> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>
> >>
>
>