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
- References:
- Re: msi again Linda.Pratt
- Navigate by Date:
- Prev:
Re: How calcExample calls myAsubProcess ? Eric Norum
- Next:
StreamDevice/ASYN 'How To' tutorial Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: msi again Linda.Pratt
- Next:
Re: msi again Benjamin Franksen
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|