More about variable references
I looked in the on-line help but didn't see anything: if ${variable}
expanded by Build Forge just like $variable? We had steps where there was a variable reference in the Directory: field of the step, like /${BUILDUTIL_DIR} where BUILDUTIL_DIR was a variable set in the top-level project (which ran a step which inlined a library which ran the step in question). The build log says .... SET BF_TAG_PHYS=EPSTreasuryTesting-314 SET BF_STEPNAME=Publish FindBugs Results SET Reference to undefined variable: BUILDUTIL_DIR SET BF_STEP_ROOT=E:\RBF\EPS_Treasury_-_Testing\EPSTreasuryTesting-314\BUILDUTIL_DIR SET BF_ROOT=E:\RBF\EPS_Treasury_-_Testing\EPSTreasuryTesting-314 .... SET BUILDUTIL_DIR=BuildUtilRtc .... I should say that I've since changed it to a constant value, but I think it was /${BUILDUTIL_DIR} and I recall I also tried /$BUILDUTIL_DIR Is there any way to have a variable reference in the Directory field of a step? -- Tim McDaniel, tmcd@panix.com |
3 answers
I looked in the on-line help but didn't see anything: if ${variable} Hi Tim, The step directory field doesn't handle environment variables. Would it be possible for your step to cd into the directory and then execute the command that you'd like. bju |
|
I looked in the on-line help but didn't see much.
Does Build Forge expand ${variable}, $variable, and %variable% identically in all cases? (Except for step commands when you set _NO_PREPARSE_COMMAND, the variable that blocks Build Forge from interpreting variables in commands sent to the agent.) Furthermore, are they equivalent in all contexts, including - commands in steps - dot commands - variable values in environments - doubtless other cases that aren't coming to mind? Is there a reason to prefer one syntax over another? (Other than the usual reason, of a variable reference being followed by literal characters that would otherwise be considered part of the variable name, like baseline_${revision}_label.) The on-line help page "Calling variables in steps" refers to only the $variable and %variable% forms. But "Interpretation of undeclared variables" allows the ${variable} form. About the only other thing I saw was in "Using Registers", "You can include register variables in notification templates; use the ${X} braced form when referencing registers in notification templates." but then "Note: You cannot use registers in commands like variables. You must first pop the value of a register to a file before you can use it." -- Tim McDaniel, tmcd@panix.com |
I like to put small Perl scripts into a Register and then use .pop to write the code to a file and subsequently execute it. So for example:
(Inlined Library) Step 1: .pop -p MY_PERL_CODE my_perl_code.pl Step 2: .bset env "MYVAR=`ratlperl my_perl_code.pl arg1 arg2`" This works great when MY_PERL_CODE is in the Register of the Project that is run. However, if MY_PERL_CODE is in the Register of the inlined Library the .pop (with or without -p) always writes 0 bytes (hence, no code). Is this simply an undocumented limitation of using Registers? |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.