Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 2 Sep 2010 16:00:20 -0500

Hi Linda,

On Thursday 02 September 2010 13:12:16 [email protected] wrote:
> (1) We make use of the default value syntax in templates, so that a
> default value is supplied if no value is specified in the substitution
> file, effectively defining "optional" macros.
...
> So the question is how do the two features of global definitions versus
> macro default values sit together? Does a global definition in a
> substitution file override a default definition of a macro of the same
> name in a template or vice versa?

If a variable has been given a value and is still in scope (i.e. it was set on 
the command-line, in a previous global{} statement in the substitution file, 
or given a value for this template expansion) any default value specified in 
the template when that variable is used will be ignored.

> Presumably a value specified in substitution pattern overrides a global
> defined value?

Yes, as long as there is actually a value given.  With dbLoadTemplate() when 
using the pattern keyword you are allows to omit substitutions at the end of 
the value list, so in the case of the substitution example below:
  global { a=1 b=2 }
  file template.db { pattern {a b c} {3} }

1. The template macro $(a=0) expands to 3 (the pattern provides that value 
which overrides the global setting and the default)
2. $(b=0) expands to 2 (the global value overrides the default, the pattern 
could provide an override for it but doesn't)
3. $(c=0) expands to its default value of 0 (nothing actually gives c a value, 
even though the pattern could)
4. $(d) would expand to $(d,undefined) which is equivalent to the original 
$(d) if you re-expand it again later.

It looks like MSI will object if you omit values for b and c in a pattern 
substitution like I do above; I haven't tried it, but the msi.c code does seem 
have an error message for that.

> Also can we be assured that changes to the behaviour for missing macros
> and empty lists, etc under discussion would not break this usage?

I hope we are making MSI and dbLoadTemplate behave more alike and in a more 
obvious manner than past versions.  If you want to make sure that our changes 
do what you expect I would encourage you to take part in testing the results 
after they've been merged into Base.  I would love to have someone contribute 
automated tests of the substitution language to include in the Base 'make 
runtests' checks, as I'm probably not going to have time to do that myself.

> (2) At what level are these truly globals?  Since a database can be
> partially expanded again and again, will the global definitions be
> passed on to the expanded file recursively?

Substitution file instructions are processed in order, as they are being 
parsed.  Within a single substitution file any global definitions are added to 
the list of known variables at the point they appear.  Global definitions 
lower in that same substitution file will be appended to the list when they 
are reached, and may override previously set values as well as add new 
definitions.  Global values cannot survive beyond the end of the substitution 
file however, so if you take the output of one run of msi that uses global 
variables and pass it through msi again using a different substitutions file, 
only the values provided in the second substitution file will be known for 
that run.

> (3) We concatenate substitution files and database files together as
> part of our build.  Introducing global sections that only go out of
> scope at the end of a file could become interesting, since there way to
> "ifdef" or "undef" in files that will become part of a larger one and
> there is no proposed syntax to delineate their actual scope.  We
> probably won't be definining global variables in our systems, however we
> do use other people's modules so we would be concerned about side
> effects if widespread use of global variables appeared in synapps, for
> instance.  Would a naming convention be useful?

I don't know whether synApps provides substitution files, or not, so I can't 
comment on that.  Our changes cannot affect distributed template files at all 
though, unless the expanded template gets used as a substitution file in a 
later round.  I agree that if you concatenate two substitution files there 
could be unwanted effects if the first defines globals that the templates of 
the second are expecting to remain undefined.  There is no way to undefine a 
variable once set, and implementing that would unfortunately require a fairly 
major rewrite of dbLoadTemplate (not sure about msi.c).

HTH,

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System