[reSIProcate] major directory reorg
david Butcher
david at purplecomm.com
Mon Jun 27 18:21:22 CDT 2005
What is the motivation for moving things out of resiprocate?
I would prefer to keep that base directory.
With sub-dirs:
- contents
- util
- dum
- repro
- dns
...
The 'r' convention seems kinda ugly and not much insurance for a namespace.
It has been hinted to me that the base directory "resiprocate" has drawn some
political resistance. What's up with that?
Apologies for opining late in the process...
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
>
More information about the resiprocate-devel
mailing list