[SR-Dev] sip-router: modules & repositories

Andrei Pelinescu-Onciul andrei at iptel.org
Fri Mar 27 23:26:32 CET 2009


On Mar 27, 2009 at 13:22, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> 
> 
> On 03/27/2009 01:08 PM, Andrei Pelinescu-Onciul wrote:
> >On Mar 27, 2009 at 11:00, Daniel-Constantin Mierla <miconda at gmail.com> 
> >wrote:
> >  
> >>Hello,
> >>
> >>I was thinking to a new idea of repository structure.
> >>
> >>The core and libraries do not overlap, so no conflict here. For modules 
> >>have three directories:
> >>- modules - store common integrated modules now (tm, db drivers) and 
> >>modules that exist only in one project
> >>- modules-k - K modules that overlap in name with S modules or other 
> >>particular K modules not moved to "modules" directory
> >>- modules-s - S modules that overlap in name with K modules or other 
> >>particular S modules not moved to "modules" directory
> >>
> >>As soon a new integration is done for overlappin modules, it will be 
> >>moved to modules and removed for modules-k/modules-s
> >>
> >>The advantage I see is only one repository. The disavantage is updating 
> >>the makefile to work with three module directories for a period of time.
> >>
> >>Opinions?
> >>    
> >
> >What should: make all and  make install do? (which set of modules)
> >  
> 
> all modules
> 
> >How would the installed version look like? (all module in the same dir?)
> >  
> different dirs:
> /usr/local/lib/sip-router/modules
> /usr/local/lib/sip-router/modules-k
> /usr/local/lib/sip-router/modules-s
> 
> >If you run make all and then start ./sr with loadmodule "textops" in
> >sr.cfg, which textops version will be used, the on from k or from s?
> >  
> there could be full path or mpath for each:
> mpath="/usr/local/lib/sip-router/modules"
> loadmodule "tm.so"
> 
> mpath="/usr/local/lib/sip-router/modules-k"
> loadmodule "textops.so"
> 
> mpath="/usr/local/lib/sip-router/modules-s"
> loadmodule "auth.so"
> 
> Cheers,
> Daniel
> 
> >If we manage to find some good answers to the above questions, then we
> >could go for it.
> >BTW: we don't even need same repos, if we have separate dirs, we could
> >experiment with git submodules (which basically tell that a subdir
> > content should be fetched from another repo).

I've added support for multiple modules dirs (the list of modules dirs
is defined in Makefile.dirs).
It's on andrei/modules_dirs branch (see
http://lists.sip-router.org/pipermail/sr-dev/2009-March/001179.html
for more details).

There are some changes when running make install: 
- each set of modules is installed in its own dir
 (e.g.: /usr/local/lib/sip-router/modules,
       /usr/local/lib/sip-router/modules-k ...)
- the modules docs are now installed in separate dirs
  (instead of /usr/local/share/doc/sr/ in 
             /usr/local/share/doc/sr/{modules,modules_s,modules_k} )

One potential problem is that all the man pages are installed in the
same dir, so modules with the same name might overwrite their man page.
However only a small number of ser modules have man page support so
far, so at least for now this is not a problem.

The modules using includes from tm would need to be updated
 (../tm/ should be replaced with ../../modules/tm/).


If we agree that this is the best way to organize the repos, we should
 decide on the names for the 3 modules directories and I'll merge my
 branch into master.
Regarding the names, they should not contain a '-' (to avoid potential
future problems with shells that don't allow '-' in env. vars), and they
should be different from any make variable name (so if you come up with
a name grep it first in Makefile* to see if it's already used).

We might consider renaming modules/ to something different (e.g.
common_mods) to avoid some confusion with old make commands
(right now make modules will make only the modules in the modules/ dir,
 using a different dir name. would permit changing make modules to make
 all the modules from all the dirs).

BTW: we are not limited to 3 modules dirs, we could use as many as we
want, we could even divide them alphabetically :-)


Andrei



More information about the sr-dev mailing list