Hello Alex,

>  Thus, it is not possible
> in advance to know which modules will be loaded, nor possible to
> iterate through some list and combine them into a string, so I cannot do:
>
>    modparam("mod1|mod2|mod3", "db_url", ...)

Regarding the modparam statement, I think you can. Unfortunately, I can't test it a.t.m., but as far as I remember I think the modparam statement succeeds even if only one of the modules listed in the module section is configured correctly. For example you can have something like
 
    modparam("carrierroute|xyz", "db_url", ....)

and work, even if xyz module doesn't exist (yet).

As another approach goes, I was thinking of having something like a preprocessor for ser cfg language. The lexer now only supports #define and #ifdef's but doesn't support macro substitution. The #define's and #ifdef's are integrated into the lexer and not an performed as a separate initial step, thus full macro support is hard to integrate.

Your code might look smth like this :

   #define DBURL "mysql://..."

   modparam("module", "db_url", DBURL)

In my opinion it will be a nice feature.

Marius 


-----Original Message-----
From: Alex Balashov [mailto:abalashov@evaristesys.com]
Sent: Fri 4/9/2010 2:53 PM
To: Marius Zbihlei
Cc: SR-Users
Subject: Re: [SR-Users] My wish

Marius,

On 04/09/2010 08:50 AM, marius zbihlei wrote:

> I see what you mean, but I don't really know if it's possible, because
> at the time of module initialization some core cfg's might not be
> registered(especially for built-in modules which are initialized before
> sr_cfg_init() ).

I understand the practical obstacles, and that it may not be possible.

The reason I would like this is that I have a flexible configuration I
reuse that has different modules loaded, primarily based on
preprocessor macros (#!ifdef ... #!endif).  Thus, it is not possible
in advance to know which modules will be loaded, nor possible to
iterate through some list and combine them into a string, so I cannot do:

    modparam("mod1|mod2|mod3", "db_url", ...)

As a result, I have to have a manual db_url setting for every module
as well as at least one DB URL as an 'sqlcon' parameter to 'sqlops'.

It is very frustrating and tedious to have to deal with problems like
this.  I have written a Perl script to recursively update all db_url's
automatically, but it is an inelegant stopgap solution.  There are
also other situations in which the ability to include some sort of PV
or variable (that is statically initialised globally) in the modparams.

--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/