Global variables set to null by default

[StephaneGerardVUB]

In many places, we see global variables initialized by default (?=) to 'null' and we would like to understand why is it so. An example:

variable WN_CONFIG_SITE ?= null;

at the beginning of personality/wn/cloning/standard. Due to the major change in the way null is considered with PAN 10.7, it prevents site level default assignment from working. For example, if you subsequently set:

variable WN_CONFIG_SITE ?= 'config/wn';

at the level of the site, it won't work.

[jrha]

@jouvin?

[jouvin]

@StephaneGerardVUB I think you are right that there is a potential problem with panc 10.7. With the last version of the template library, we have not seen problems at LAL so I expect they will be not to many... As for null vs. undef as a default value, it used to be a little bit a matter ot taste as the effect was the same. But there are a few cases where it is intentional to offer a 3-state variable: defined, undefined, null with null meaning for example that the default value should not be used so that the variable remains "undefined" (with no value). So there is no easy automatic update.

As for wn/cloning, it is part of the legacy. I don't see any good reason to use them anymore. It was a trick to speed up the compilation of a large number of WNs at the time of SPMA where package handling was eating most of the compilation time. It is no longer the case with YUM and I don't think there is any real advantage to use this cloning trick anymore. At least at LAL, we stopped to use it when we moved to YUM.

[StephaneGerardVUB]

@jouvin Here at IIHE, we had problems because in template global_variables, we use default affectations. For example:

variable UI_CONFIG_SITE ?= 'config/ui';

For us, it is useful to keep it like that because it allows us to override in the object template before the inclusion of the machine-type in order to make some tests.

Regarding wn/cloning, sorry, I took a wrong example.