Re: [reSIProcate] major directory reorg, retry
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@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