Re: [reSIProcate] major directory reorg
There is still a resiprocate directory. contents, and dns are
subdirectories. rutil, rdns, dum, repro are parallel to it. It is the
sip directory that was removed.
On 6/27/05, david Butcher <david@xxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxx>:
>
> > 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
> >> >>
> >> >>
> >>
> >>
> > _______________________________________________
> > 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
>