[SR-Dev] exlude module from the compilation

[Andrei Pelinescu-Onciul]

On Mar 16, 2009 at 13:08, Henning Westerholt <henning.westerholt at 1und1.de> wrote:
> On Friday 13 March 2009, Andrei Pelinescu-Onciul wrote:
> > > thanks for the pointer, thats a cool feature. Some things i noticed
> > > during my tests of the 'kamailio-3.0' branch: It seems that the library
> > > dependencies of the modules are recompiled again for every module. I
> > > thought you fixed something in this regards in the main branch, perhaps
> > > this is not yet integrated into this? But i don't remember exactly, its
> > > of course not a big issue.
> >
> > It's fixed, but for ser :-)
> 
> Hi Andrei,
> 
> ok. :-) 
> 
> > The problem is that we always save all the options a module or a lib was
> > compiled with and then on re-compile we check if the options (defines)
> > have changed. If they did => recompile everything.
> > This avoids problems like compiling a module with -DDBG_QM_MALLOC, then
> >  doing some change and compiling without it (which without this extra
> >  check might work but will produce coredumps at runtime).
> > The DEFS and INCLUDES are saved in makecfg.lst in each modules or lib
> > directory.
> 
> Understand. We detect this on runtime in the module loader, if there is a 
> mismatch in the compile flags of core and modules the server will not start.

Right, we do it too, in fact it's in ser before the openser fork (but I
forgot about it :-)). So replace coredump in the above paragraph with
"sr will refuse to start".

> 
> > The problem with libs re-compiling happens because the list of lib
> > defines changes as new modules using the lib are compiled. This happens
> >  because of the different DEFS in different modules (when a module
> >  makefile calls the lib makefile its local DEFS will be passed to the
> >  lib).
> > In ser we don't use modules DEFS so much so we haven't seen it so far.
> >
> > We either need a long list of DEFS excluded from the checks (that don't
> > trigger a recompile), or a separate way to specify "local" DEFS, just
> > for modules or libs (e.g. using MOD_DEFS instead of DEFS).
> > Also we must eliminate abuses like using DEFS for passing includes,
> > compiler options a.s.o.
> >
> > > A more problematic bug i run into is that the compilation of
> > > the 'perl' module run into a endlees loop during the make, because i
> > > don't have the necessary dependencies installed, and make somehow don't
> > > detects that the compilation fails.
> >
> > It's because of DEFS+=`perl -MExtUtils::Embed -e ccopts` in the module
> > Makefile. This causes the saved DEFS to be different (they will containt
> >  "`perl -MExtUtils::Embed -e ccopts`") from the ones actually used
> >  (the output of `perl -MExtUtils::Embed -e ccopts`). No substitution can
> >  be used in DEFS.
> >
> > A simple way to fix it is to replace:
> >  DEFS+=`perl -MExtUtils::Embed -e ccopts`
> > with
> >  PERLCCOPST=$(shell perl -MExtUtils::Embed -e ccopts)
> >  DEFS+=$(PERLCCOPTS)
> 
> That solution stopped the endless loop in the sip-router, but works 
> unfortunally not in the kamailio, here this breaks the compilation. But i 
> don't know that much about how this perl embedding process works, would be 
> cool if somebody that really use this module could take a look.
> 
> > I'll try to think of a solution for using separate DEFS names for modules,
> > libs, and common part.

It's in sip-router right now, but still needs some testing (the ser
version works, but the sr version is slightly different).

Andrei