#1
|
|||
|
|||
Failures in called vbp don't stop caller
We have a fairly large build where a main .bld file calls other .bld files. The problem we are having is that in one particular .bld file if a failure occurs, the build correctly stops, calls the failure steps and then says "build completed successfully" the caller thinks that everything went fine and runs until it needs something from the failed build and it finally fails.
Most of the called .bld files work correctly, i.e. if they fail the caller fails too. But one in particular does not, it can fail but the caller continues. We've examined and re-examined and I'm not ignoring failures. The biggest difference between the .bld files that work properly, and the one that doesn't is that the one that doesn't has failure steps. The .bld files that do work ok do not have failure steps. So it almost looks like if you do failure steps that VBP thinks the problem was handled and it can say everything is OK. If this is the case, this seems counter-intuitive (ie bug). I didn't see that the documentation indicated this behavior. |
#2
|
|||
|
|||
I'm not able to reproduce this behavior here. Attached is a sample project (parent.bld) that calls another project (child.bld). The child project has a regular project step that will fail and some failure steps. The parent project calls the child and has its own failure step. I'm seeing the expected behavior of
1) the parent building the child project 2) the child main step failing 3) the child project's failure steps building 4) the child process exiting with a non-zero exitcode 5) the parent project treating as a step failure and 6) building its failure steps and 7) stopping with a build failure If you can set up a reproducible case and post it we can take a look. Also include the info from Help | About | Install Info. |
#3
|
|||
|
|||
I'm actually not surprised that you can't reproduce it. I was kinda dreamfully hoping that I'd get a "oh yeah, we're fixing it in the next release and the current work around is..." I wish I could setup a reproducible scenario. I just know that for most child build spawns it works fine but one in particular does not. And I've had others look into it and they can't figure it out either. It is a fairly complex build with many components and dependencies. Lots of EXE's COM components, DLLs and .NET assemblies lots of languages and dozens of visual studio projects and solutions.
Sigh, I'll keep plugging away |
#4
|
|||
|
|||
I am having the exact same problem!
I am a parent build script which calls a child, which builds a whole series of DLLs and Exes. If one of these build fails, the failure steps are executed but it returns a success to the parent. I thought it was something to do with the number of steps in the child failure steps, so I put a err.raise as the last step, but without an success. Any thoughts would be gratefully appreciated. George |
#5
|
|||
|
|||
We were able reproduce this behavior in the following scenario: If a subroutine step was the initial step that failed, and the failure steps also call a subroutine, the child project returns success rather than failure upon completing the failure steps. We have a test build available at http://www.kinook.com/Download/VisBuildProTest.exe that you can try to see if it resolves the problem in your case.
|
|
|