1 Jul
2009
1 Jul
'09
10:35 a.m.
i changed
NAME=srcmd
in utils/sercmd/Makefile
but that alone didn't make it, because main Makefile has
# which utils need compilation (directory path) and which to install
# (full path including file name)
utils_compile= utils/gen_ha1 utils/sercmd
utils_bin_install= utils/gen_ha1/gen_ha1 utils/sercmd/sercmd
and make results in error:
make[2]: Entering directory `/usr/src/trunk-src/sip-router/utils/sercmd'
gcc -Wall -g -O2 -DNAME='"srcmd"'
-DVERSION='"0.2"' -DUSE_READLINE -c parse_listen_id.c -o
parse_listen_id.o
gcc -Wall -g -O2 -DNAME='"srcmd"'
-DVERSION='"0.2"' -DUSE_READLINE -c sercmd.c -o sercmd.o
gcc -Wl,-O2 -Wl,-E parse_listen_id.o sercmd.o -lresolv -lsctp -lreadline -lncurses -o
srcmd
make[2]: Leaving directory `/usr/src/trunk-src/sip-router/utils/sercmd'
ERROR: utils/sercmd/sercmd not compiled
what is the proper fix?
my suggestion is to add to Makefile.defs a new variable SHORT_NAME,
which could default to ser:
SHORT_NAME=ser
and then use that Makefile:
utils_bin_install= utils/gen_ha1/gen_ha1 utils/sercmd/$(SHORTNAME)cmd
and also in utils/sercmd/Makefile:
NAME=$(SHORT_NAME)cmd
and also in modules_s/ctl/ctl_defaults.h instead of ser:
#define DEFAULT_CTL_SOCKET "unixs:/tmp/ser_ctl"
-- juha
1 Jul
1 Jul
6:36 p.m.
On Jul 01, 2009 at 10:35, Juha Heinanen <jh(a)tutpro.com> wrote:
i changed
[...]
what is the proper fix?
my suggestion is to add to Makefile.defs a new variable SHORT_NAME,
which could default to ser:
SHORT_NAME=ser
and then use that Makefile:
utils_bin_install= utils/gen_ha1/gen_ha1 utils/sercmd/$(SHORTNAME)cmd
Changing the name of the binaries would be confusing.
If you run make cfg SHORT_NAME=sip-router; make all and then
make cfg SHORT_NAME=ser; make proper you will still remain with
uncleaned files.
How about only installing using a different name? Let it compile to
sercmd, but make install would install it under UT_NAME (one could
do a sed -e 's/^ser/$(UT_NAME)' in install-utils:).
and also in utils/sercmd/Makefile:
NAME=$(SHORT_NAME)cmd
and also in modules_s/ctl/ctl_defaults.h instead of ser:
#define DEFAULT_CTL_SOCKET "unixs:/tmp/ser_ctl"
That would be even more tricky. You would have to fix possible mentions
in the docs and even then differently named sercmds will use different default
sockets => lost of "support" problems.
Andrei
6:54 p.m.
Andrei Pelinescu-Onciul writes:
that is what you get when/if the plan is to have build several products
with different names from the same sources. a common name sip-router
would have been fine with me, but not with some other people. vote on
this is still to be done, however.
-- juha
How about only installing using a different name? Let
it compile to
sercmd, but make install would install it under UT_NAME (one could
do a sed -e 's/^ser/$(UT_NAME)' in install-utils:).
since utils/sercmd/Makefile has
NAME=sercmd
it would be cleaner to add to Makefile.defs
SERCMD_NAME=sercmd and then in utils/sercmd/Makefile replace the above
with
NAME=$(SERCMD_NAME)
and then in main Makefile
utils_bin_install= utils/gen_ha1/gen_ha1 utils/sercmd/$(SERCMD_NAME)
on the other hand, why can't installation be done in
utils/sercmd/Makefile under name NAME?
and also in
modules_s/ctl/ctl_defaults.h instead of ser:
#define DEFAULT_CTL_SOCKET "unixs:/tmp/ser_ctl"
That would be even more tricky. You would have to fix possible mentions
in the docs and even then differently named sercmds will use
different default
sockets => lost of "support" problems. 
8:15 p.m.
I do not think every utility has to be renamed. Anyhow there are kamctl
and serctl that do different things and they have to be kept. Also
rtpproxy was in the cvs repository as a related project, so keeping this
kind of related tools with different names should be fine. Related are
also serweb, sems, etc ... sticking to current name is better imo.
BTW gen_ha1 is something very simple to do from command line:
echo -n "user:domain:password" | md5sum | $AWK '{ print $1 }'
Daniel
On 07/01/2009 05:54 PM, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
that is what you get when/if the plan is to have build several products
with different names from the same sources. a common name sip-router
would have been fine with me, but not with some other people. vote on
this is still to be done, however.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com/
How about only installing using a different name?
Let it compile to
sercmd, but make install would install it under UT_NAME (one could
do a sed -e 's/^ser/$(UT_NAME)' in install-utils:).
since utils/sercmd/Makefile has
NAME=sercmd
it would be cleaner to add to Makefile.defs
SERCMD_NAME=sercmd and then in utils/sercmd/Makefile replace the above
with
NAME=$(SERCMD_NAME)
and then in main Makefile
utils_bin_install= utils/gen_ha1/gen_ha1 utils/sercmd/$(SERCMD_NAME)
on the other hand, why can't installation be done in
utils/sercmd/Makefile under name NAME?
and also
in modules_s/ctl/ctl_defaults.h instead of ser:
#define DEFAULT_CTL_SOCKET "unixs:/tmp/ser_ctl"
That would be even more tricky. You would have to fix possible mentions
in the docs and even then differently named sercmds will use
different default
sockets => lost of "support" problems.
8:50 p.m.
Daniel-Constantin Mierla writes:
I do not think every utility has to be renamed. Anyhow
there are kamctl
and serctl that do different things and they have to be kept.
i'm not asking renaming of all utilities. in fact, i'm not asking to
rename any, but a POSSIBILITY to configure the name of serctl that deals
with core and should thus be independent from ser or kamailio.
Also
rtpproxy was in the cvs repository as a related project, so keeping this
kind of related tools with different names should be fine. Related are
also serweb, sems, etc ... sticking to current name is better imo.
all those you list are not mandatory for managing of the core like
serctl is and i don't care how they are named. if you want to stick to
ser ralated name of serctl, then do so, but don't force everyone else
to do the same.
-- juha
9:05 p.m.
On 07/01/2009 07:50 PM, Juha Heinanen wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
Daniel-Constantin Mierla writes:
there is a problem now because of different database schemas. if you use
kamailio modules, then you have to stick to kamctl and not use serctl.
All these renaming done right now will create confusion as many things
get broken while testing and most of documentation is not updated.
kamctl can communicate with core via MI, sercmd communicates via RPC.
Because I added a new rpc command, most of MI stuff (not all) can be
executed via rpc as well, otherwise would have been useless for kamailio
modules users. However that does not make kamctl obsolete at all.
It is very easy to do a search/replace in code, but what about all
references in web documentation?
I fail to see the reason for all this mess right now, when we haven't
finished with code integration. For those writing docs to help testers
is hard to manage all those. I wrote wiki tutorials that shows how to
get default config file running with sip router core. Just have in mind
that ad-hoc renaming breaks many things.
Daniel
I do not think every utility has to be renamed.
Anyhow there are kamctl
and serctl that do different things and they have to be kept.
i'm not asking renaming of all utilities. in fact, i'm not asking to
rename any, but a POSSIBILITY to configure the name of serctl that deals
with core and should thus be independent from ser or kamailio.
Also
rtpproxy was in the cvs repository as a related project, so keeping this
kind of related tools with different names should be fine. Related are
also serweb, sems, etc ... sticking to current name is better imo.
all those you list are not mandatory for managing of the core like
serctl is and i don't care how they are named. if you want to stick to
ser ralated name of serctl, then do so, but don't force everyone else
to do the same.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:15 p.m.
Daniel-Constantin Mierla writes:
there is a problem now because of different database
schemas. if you use
kamailio modules, then you have to stick to kamctl and not use
serctl.
i'm not using kamctl to manage database tables. serctl with mi
extension is all i need and it seems to work fine for the modules that i
use.
All these renaming done right now will create
confusion as many things
get broken while testing and most of documentation is not updated.
how many times i need to say that i'm not asking to rename anything.
It is very easy to do a search/replace in code, but
what about all
references in web documentation?
currently man pages refer to sip-router web site. if you want them to
refer to kamailio web site instead, then we need to make another copies
of them.
I fail to see the reason for all this mess right now,
when we haven't
finished with code integration. For those writing docs to help testers
is hard to manage all those. I wrote wiki tutorials that shows how to
get default config file running with sip router core. Just have in mind
that ad-hoc renaming breaks many things.
you don't seem to be reading what i write. i'm not proposing to rename
anything.
-- juha
9:27 p.m.
On 07/01/2009 08:15 PM, Juha Heinanen wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
Daniel-Constantin Mierla writes:
sometimes this is the easy way for many - not using, not care - but
leaves the project in an incoherent state, which I prefer to avoid as
much as possible.
Probably was a bit of rush from me this time, trying not to get other
renamings in very short time and then fix backwards.
From what you say, adding a way to change easily names, is just fine
for me.
Thanks,
Daniel
there is a problem now because of different
database schemas. if you use
kamailio modules, then you have to stick to kamctl and not use
serctl.
i'm not using kamctl to manage database tables. serctl with mi
extension is all i need and it seems to work fine for the modules that i
use.
All these
renaming done right now will create confusion as many things
get broken while testing and most of documentation is not updated.
how many times i need to say that i'm not asking to rename anything.
It is very easy to do a search/replace in code,
but what about all
references in web documentation?
currently man pages refer to sip-router web site. if you want them to
refer to kamailio web site instead, then we need to make another copies
of them.
I fail to see the reason for all this mess right
now, when we haven't
finished with code integration. For those writing docs to help testers
is hard to manage all those. I wrote wiki tutorials that shows how to
get default config file running with sip router core. Just have in mind
that ad-hoc renaming breaks many things.
you don't seem to be reading what i write. i'm not proposing to rename
anything.
-- juha
9:13 p.m.
On 07/01/2009 07:50 PM, Juha Heinanen wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/
Daniel-Constantin Mierla writes:
btw, I forgot to mention, if by asking a possibility to configure the
name for binary, tools, etc. you mean that you will implement and submit
a patch when it is the case, that is very fine, improvements are welcome
always.
What I wanted to say is that I do not want replacing defaults with other
static names now. And I won't put efforts in such things before we get
to testing phase for new relase.
Daniel
I do not think every utility has to be renamed.
Anyhow there are kamctl
and serctl that do different things and they have to be kept.
i'm not asking renaming of all utilities. in fact, i'm not asking to
rename any, but a POSSIBILITY to configure the name of serctl that deals
with core and should thus be independent from ser or kamailio.
Also
rtpproxy was in the cvs repository as a related project, so keeping this
kind of related tools with different names should be fine. Related are
also serweb, sems, etc ... sticking to current name is better imo.
all those you list are not mandatory for managing of the core like
serctl is and i don't care how they are named. if you want to stick to
ser ralated name of serctl, then do so, but don't force everyone else
to do the same.
-- juha
9:17 p.m.
Daniel-Constantin Mierla writes:
btw, I forgot to mention, if by asking a possibility
to configure the
name for binary, tools, etc. you mean that you will implement and submit
a patch when it is the case, that is very fine, improvements are welcome
always.
of course i would commit the changes needed that allow easy
configuration of the name for serctl command.
What I wanted to say is that I do not want replacing
defaults with other
static names now. And I won't put efforts in such things before we get
to testing phase for new relase.
i have not proposed to change any defaults.
-- juha
5623
days inactive
5623
days old
9 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
jh＠tutpro.com