passing parameters to sub-projects and environment variables

[daveronson]

I have a master visual build project that calls a number of sub visual build projects using the VisBuildPro Project action. 7 project level (with env. variable checked) macros are passed as parameters each time to the sub projects. The sub projects call out to some batch files using the "Run Program" action in a subroutine. The batch files use the macros to do various things.

Everything works fine in the VisBuildPro GUI app but when trying to build using the VisBuildCmd app the macros are unavailable to the batch files in the sub-projects.

I have read through the help and other posts and I have found a a few workarounds/solutions to my problem. None are as simple as I'd like. I'm curious as to whether this is expected behaviour of the VisBuildCmd app?

[kinook]

When you have macros that are marked to update environment variables, you don't need to (and actually probably should not) pass them as parameters to the child project; when the build starts, all existing macros that are marked to update env vars are updated in the current process env block, which is (recursively) inherited by any processes started by VBP (and are also available as system macros in the child VBP instance if 'Tools | Application Options | Macros | Include env vars in system macros' is checked).

So, when the parent build starts, the env block will be updated with the current project macro values. The child VBP process will inherit those env values, as will the batch file that is invoked by the child project.

I made a simple test here (attached) and it produces the expected output when built via the GUI or console app:

12/15/2004 4:17:09 PM: --------------------Starting Build: 'C:\Temp\batchparent.bld'--------------------
12/15/2004 4:17:09 PM: Building project step 'Project steps'...
12/15/2004 4:17:09 PM: Building project step 'call child'...
12/15/2004 4:17:09 PM: --------------------Starting Build: 'C:\Temp\batchchild.bld'--------------------
12/15/2004 4:17:09 PM: Building project step 'Project steps'...
12/15/2004 4:17:10 PM: Building project step 'call batch file'...
VAR1 = 12/15/2004 4:17:09 PM
VAR2 = test var2 12/15/2004 4:17:09 PM


I'm not sure what could be causing VisBuildCmd to have different behavior in your case (even if you are passing the macro values to the child project, since this won't affect the env block). First take a look at the attached sample and see if it works correctly for you. If it does, you should be able to tweak your project to match. Otherwise, we may need to investgiate a little further to see what's different about your configuration.

[daveronson]

Thansk, your sample worked fine (and cleared up a misunderstanding about this). This led me to try a few things.

It took a bit for me to figure out what was different. The difference is when I use the VisBuildCmd app I am running it from a scheduled task. I have a scheduled task that passes some macros (e.g. var1=value1 var2=value2) that in essence override the project level macros. The macros I pass in are definitely the ones that give me trouble.

The reason I set it up this way was so I could have different build configurations (eg. target environment, branch vs. trunk builds, etc.) all pre-configured in scheduled tasks. I just need to run the one I want or schedule it to run at night.

Anything you can think of to accomplish this?

[kinook]

Ah. That would explain it, since the macro values you pass in become temporary macros (which override project macros) and there is no way, when passed on the command-line, to specify that the temporary macros update env vars.

One workaround would be to migrate your batch file code into VBP projects. Then you wouldn't have to worry about setting env vars.

Another option would be to pass in the temp macros under a slightly different name (i.e, prefixed with _ or x), then add Set Macro steps at the start of the build to set the real temp macros (marked to update env vars, these will override the project macros) from the alternate temp macros only if the alternate temp macro exists. When such a Set Macro step is executed during a build, it also updates the environment block with that macro's value.

Something we'll consider doing, which would probably solve the problem, would be to add a command-line flag to indicate that all temporary macros being passed should be marked to update env vars.

[daveronson]

Thanks. I'll put a workaround in place.

[daveronson]

Is there any way to iterate through the passed in macros and convert them to environment variables so they are available to the sub-projects?

I tried this:
Dim macros, macro
Set macros = Application.Macros(vbldMacroTemporary)
For each macro in macros
macro.AddAsEnvVar = true
Next

but this didn't work for the sub-projects. I also tried adding the macros as project level macros but the VisBuild help says the environment variable won't take effect until the build is restarted.

For now I have created some "hard coded" SET MACRO actions that get set at the start of the master build.

Any thoughts?

[kevina]

Sure, Visual Build Professional is flexible enough to do basically anything <grin>!

See the Environment Variables section of the Advanced.bld sample (specifically the "Create via script" step). That step does exactly what you are asking for (you can modify it with your for loop to dynamically add macros instead of the hard-coded example macros).