[reSIProcate] major directory reorg, retry
david Butcher
david at purplecomm.com
Mon Jun 27 20:27:19 CDT 2005
Ok, after some offline discussions, here's take two:
Namespaces matter, both in code and in directories.
Here is my proposal:
resip/util
resip/stack
resip/contents
resip/dum
resip/dns
These are arguably independent; their respective developers may wish to
put them
in separate repositories, thought that will certainly have costs.
msrp/
repro/
msrp and repro will depend on resip/util. I don't see an issue with this, but
there are hints this will cause problems. I would like to understand the
issues.
I much prefer
#include "resip/util/Mutex.hxx"
to:
#include "rutil/Mutex.hxx"
for clarity and namespace mapping.
david
> Quoting Fischl jason <jason.fischl at gmail.com>:
>
>> 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 at nostrum.com> 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 at 2imagineit.net> 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 at gmail.com>
>>> >>>> To: resiprocate <resiprocate-devel at list.sipfoundry.org>
>>> >>>> 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 at list.sipfoundry.org
>>> >>>>>
>>> >>>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>> >>>> _______________________________________________
>>> >>>> resiprocate-devel mailing list
>>> >>>> resiprocate-devel at list.sipfoundry.org
>>> >>>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>> >>>>
>>> >>> _______________________________________________
>>> >>> resiprocate-devel mailing list
>>> >>> resiprocate-devel at list.sipfoundry.org
>>> >>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>> >>
>>> >>
>>>
>>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.sipfoundry.org
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
More information about the resiprocate-devel
mailing list