Forum: Cfengine Help
Subject: Suppressing suprious parser warnings?
Author: sauer
Link to topic: https://cfengine.com/forum/read.php?3,21316,21316#msg-21316
So, I have a specific and a general question.
Specific: In my update.cf, I define a variable which specifies the subversion
branch from which I'd like to pull the configurations on a given machine. Say
I have a test branch and a production branch, some machines get the testing
branch, and once parts of testing are proven stable, I update the production
branch. I define a list of machines which get the testing branch, and
everythign else gets the production branch. But I have more than one testing
branch, so I basically have classes (use_test1_src, use_test2_src, etc) defined
for each corresponding list of systems which get the test1 branch or the test2
branch.
Therefore, I have code similar to this in servertypes.cf (which is
bundlesequence'd prior to the update.cf):
classes::
"use_test1_src" or => { @(test1_server_list) };
"use_test2_src" or => { @(test2_server_list) };
"use_special_src" expression => classmatch("use)[^_]+_src");
and then in my update bundle, I have something like:
vars::
!use_special_src:: "src" string => "$(basepath)/default"
use_test1_src:: "src" string => "$(basepath)/test1"
use_test2_src:: "src" string => "$(basepath)/test2"
And this all works just great. Except that I get these inaccurate warnings
from the initial variable parsing stage when I use -I or -v:
!! Duplicate selection of value for variable "src" in scope update
Now, everything ultimately works as intended. But, as a perl developer who
always does a "use warnings" (etc), it really bugs me to have ignoreable
warnings thrown for working code; I expect warnings to go away when I structure
things in a "better" way. I kindof dislike the idea of defining the variables
with a policy of free/overrideable when I really don't want them overwritten,
but that may be something for this.
I have a similar issue when I do something like
list1 slist => {"1", "2", "3"};
var1 string => join("x", "list1");
var2 string => "$(prefix) $(var1)";
That also works, but it gripes that I have unresolved variables in the $var2
RHS. In verbose mode, it's revealed that cfengine is actually griping because
"list" may not be defined by the time join() runs, so $var1 may be undefined.
I assume this is because the initial variable parser finds strings first, then
slists afterwards. Either way, it's another warning which is very similar to
that first one, and it seems harder to safely suppress - unless perhaps I move
the list into one method and the other vars into a second method to force the
order of evaluation. That seems clunky, and makes a mess of my otherwise
pretty structure :)
So, the general question is if there's a more universal way to provide hints or
somehow indicate to the variable parser that I don't want to see very specific
warnings? Or are my "let variables be overrideable" and "shift some variable
definitions into a module" thoughts the best we can do for now?
PS: I'm preempively shaking my fist angrily in the general direction of the
first person to suggest piping through "grep -v '^ !!'". :)
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
