On Mar 27, 2009 at 13:22, Daniel-Constantin Mierla <miconda(a)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(a)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