[sr-dev] Makefile troubles

[Olle E. Johansson]

21 jul 2010 kl. 11.03 skrev Daniel-Constantin Mierla:

> 
> 
> On 7/21/10 10:53 AM, Timo Reimann wrote:
>> Daniel-Constantin Mierla wrote:
>>   
>>> 
>>> On 7/21/10 10:46 AM, Timo Reimann wrote:
>>>     
>>>> Daniel-Constantin Mierla wrote:
>>>> 
>>>>       
>>>>>>>>> Friends, I feel like an idiot. I've been trying to compile Kamailio
>>>>>>>>> 3.0.2 with presence for  hours. I have edited make files, read the
>>>>>>>>> INSTALL and tried many things... I just can't get it.
>>>>>>>>> 
>>>>>>>>> I think something is wrong in the build system and the
>>>>>>>>> documentation.
>>>>>>>>> I will fight a bit more to get some more detailed information for
>>>>>>>>> you
>>>>>>>>> to work with, but it worries me that I can't figure this out by
>>>>>>>>> myself. Something propably needs to change to make Kamailio more
>>>>>>>>> "oej-compatible" ;-)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>                 
>>>>>>>> Frankly, I feel similar about 3.0's build system. When I build sr the
>>>>>>>> other day I too had the impression that docs and Makefiles don't
>>>>>>>> match
>>>>>>>> up nicely. IMHO, Kamailio 1.5's way of building was more intuitive.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>               
>>>>>>> maybe the confusions come now from multiple directories storing the
>>>>>>> modules, in some cases you would need to use the name of the directory
>>>>>>> 
>>>>>>> One of the features of the new makefile system is the ability to
>>>>>>> remember settings by two generated config files:
>>>>>>> - config.mak
>>>>>>> - modules.lst
>>>>>>> 
>>>>>>> In this way is not needed to give all command line parameters to make
>>>>>>> and make install everytime.
>>>>>>> 
>>>>>>> 
>>>>>>>             
>>>>>> Ah ok, good to know.
>>>>>> 
>>>>>> So is there still a way to disregard those two files for a specific
>>>>>> Make
>>>>>> run and use parameters given on the command-line only? Or do you always
>>>>>> have to edit config.mak and modules.lst?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>           
>>>>> these files are auto-generated. If you run 'make cfg', e.g.,:
>>>>> 
>>>>> make PREFIX=/usr/local/kamailio FLAVOUR=kamailio
>>>>> include_modules="db_mysql presence presence_xml" cfg
>>>>> 
>>>>> will create the config.mak and modules.lst with appropriate variable
>>>>> set.
>>>>> 
>>>>> If you do not run 'make cfg', is automatically run by simple 'make'
>>>>> command, without any extra parameters.
>>>>> 
>>>>>         
>>>> Let's assume that I usually build a set of modules given in modules.lst.
>>>> Now, say I want to run another build where some modules missing in the
>>>> config file should be build, and let's also assume that I explicitly
>>>> want to ignore a bunch of modules which are included in modules.lst. The
>>>> build deviations should affect a single build run only but not any
>>>> subsequent builds.
>>>> 
>>>> Would I need to change the config file(s) for that special build (and
>>>> later revert them), or could I do it by means of giving Make parameters
>>>> that override cfg settings?
>>>> 
>>>>       
>>> as said, these files are auto-generated. In the 1.x, you had to do:
>>> 
>>> make PARAMETERS all; make PARAMETERS install
>>> 
>>> now you can do:
>>> 
>>> make PARAMETERS cfg; make all; make install
>>> 
>>> You can overwrite in some cases, for example:
>>> 
>>> make modules modules=modules_k/pdt
>>> 
>>> will compile only the pdt module from K.
>>>     
>> Gotcha. Thanks for clearing things up.
>>   
> welcome. The new makefile system is 'new' :-) for me as well, but looks more powerful. Another thing that I like is grouping modules:
> 
> make every-module group_include=kpresence
> 
> will build all K presence modules. The pre-defined groups follow closely debian packaging - see Makefile.
> 
> Also, when you need to add a new module in compile list, you edit modules.lst, not touching Makefile means only that extra module will be compiled, not a full recompilation of everything (core+modules).

My summary of this is that we have released a product without proper instructions in the INSTALL/README ;-)
We need to fix that.

/O