Kinook Software Forum

Go Back   Kinook Software Forum > Visual Build Professional > [VBP] Suggestions
FAQ Community Calendar Today's Posts Search

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 10-18-2006, 06:52 PM
mike_laff mike_laff is online now
Registered User
 
Join Date: 10-18-2006
Posts: 3
Exclamation Failure handling in groups and subroutines

I've used your product now for a few weeks to attempt produce a complex build of a number of projects. However, I find the error handling of groups and subroutines in general very confusing and in a complex project (with error handling!) it appears that groups and subroutines are relatively useless.

For example, in both groups and subroutines, exactly what effect do the "On Step Failure" properties do? Groups and subroutines never fail!

If this does nothing surely it should be removed (on groups/subs) to avoid confusion and time wasting trying to use them. However, use of these properties could be made valuable by extending them with an option to exit from the group/subroutine with a status. I believe this would be an extremely useful enhancement.

ie. Build failure steps: [ ] (blank for all)
(o) continue building or
(o) exit group/subroutine with success (?)
(o) exit group/subroutine with fail

For a basic example of why this would be used....

I wish to build 20 projects. Each project requires a version change, a VC build and a setup built. I create a subroutine to do these 3 steps (could be 10 or more in reality) and call the subroutine 20 times from the main project steps using parameters. Naturally, there is no point trying to build the setup if the VC build fails but I do wish the other 20 projects to be allowed their own attempt at building. With diligent use of the "Continue building" option and lots of conditional build rules, I have actually managed to achieve this but it was very cumbersome for a requirement that seems so basic.

Apart from this one semi-serious failing, however, it's a magic product - keep up the good work
Reply With Quote
  #2  
Old 10-19-2006, 02:37 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
Re: Failure handling in groups and subroutines

Quote:
Originally posted by mike_laff
I've used your product now for a few weeks to attempt produce a complex build of a number of projects. However, I find the error handling of groups and subroutines in general very confusing and in a complex project (with error handling!) it appears that groups and subroutines are relatively useless.

For example, in both groups and subroutines, exactly what effect do the "On Step Failure" properties do? Groups and subroutines never fail!

If this does nothing surely it should be removed (on groups/subs) to avoid confusion and time wasting trying to use them.
The On Step Failure settings apply to any step that fails, whether in a group or subroutine or not.

Quote:
However, use of these properties could be made valuable by extending them with an option to exit from the group/subroutine with a status. I believe this would be an extremely useful enhancement.

ie. Build failure steps: [ ] (blank for all)
(o) continue building or
(o) exit group/subroutine with success (?)
(o) exit group/subroutine with fail

For a basic example of why this would be used....

I wish to build 20 projects. Each project requires a version change, a VC build and a setup built. I create a subroutine to do these 3 steps (could be 10 or more in reality) and call the subroutine 20 times from the main project steps using parameters. Naturally, there is no point trying to build the setup if the VC build fails but I do wish the other 20 projects to be allowed their own attempt at building. With diligent use of the "Continue building" option and lots of conditional build rules, I have actually managed to achieve this but it was very cumbersome for a requirement that seems so basic.

Apart from this one semi-serious failing, however, it's a magic product - keep up the good work
Not a bad idea. I suspect the reason it hasn't been requested before now are:
1) It's more common to do all that from a single step in VBP (a Make VC or Make VS.NET step to set/increment versions, specifying a workspace or solution containing all 20 projects + setup projects)

2) If broken out into multiple steps for each project, it's still probably more common to stop on any step failure and correct the problem before continuing (later projects will likely depend on the earlier ones, etc.).

3) Even when continuing, there probably aren't many steps that could fail and the build should still continue, so

what you could do: in the subroutine, mark the build step to continue on failure, and add an Exit step (configured to exit with a success status) after it with a build rule of

%LASTSTEP_STATUS% does not equal 0

This will exit from the subroutine at that point if the build step failed, and the build will continue at the next project step.

If you do end up with several steps in the subroutine that should trigger an exit of the subroutine on failure, you could get more elaborate and use project-level step script events to store the status and conditionally skip the remaining steps.
http://www.visualbuild.com/Manual/scriptevents.htm
Reply With Quote
  #3  
Old 10-21-2006, 09:08 PM
mike_laff mike_laff is online now
Registered User
 
Join Date: 10-18-2006
Posts: 3
Hi, thanks for the feedback.

The On Step Failure settings apply to any step that fails, whether in a group or subroutine or not.

--- My point here is that subroutine/group steps (the step itself not the steps within) cannot fail as they do nothing. Therefore, is there any point to these failure step settings? I for one, nievely thinking that the subroutine failure settings would do something if the steps within the subroutine failed, wasted hours trying to use these settings. I think it would be helpful to save others the same trouble.

1) It's more common to do all that from a single step in VBP (a Make VC or Make VS.NET step to set/increment versions, specifying a workspace or solution containing all 20 projects + setup projects)

--- I'm unsure what you mean here. I'm trying to put together a single nightly build (1 .bld file) of around 30 big products.

The first part of my build process builds around 50 shared libraries/components - all the libraries are simple VC/VS builds, all the components use a subroutine to (a) update the version, (b) do a VC/VS Make and (c) update source control with new version. Any faillure in this part stop the build completely.

The second part of my build then builds the products themselves. Each product uses a subroutine to (a) update the version, (b) do a VC/VS Make and (c) update source control with new version. Some subroutines are much more complex. Most products also and have their own independant libraries/components. Here, I want every product to have an opportunity for building.

The third part of my build does the setups. Each setup uses a subroutine to (a) update the version, (b) do a Setup Make and (c) update source control with new version. Again, I want every setup to have an opportunity for building.

2) If broken out into multiple steps for each project, it's still probably more common to stop on any step failure and correct the problem before continuing (later projects will likely depend on the earlier ones, etc.).

--- I see you point, but I would imagine that a fair number of people would have projects similar to mine where we have a number of shared components/libraries (that do require a complete build stop) followed by a number of projects/products that should each have a chance of building in their own right. This can dramatically save time on big projects as you can potentially fix two (or more) problems without having to restart the build twice (or more!). This has been mentioned a few times in these forums in the past.

3) Even when continuing, there probably aren't many steps that could fail and the build should still continue, so

what you could do: in the subroutine, mark the build step to continue on failure, and add an Exit step (configured to exit with a success status) after it with a build rule of

%LASTSTEP_STATUS% does not equal 0

--- This does not work if you run any failure steps in the last step. By the time the Exit step gets to evaluate this status, the last failure step will have already modified the %LASTSTEP_STATUS% back to 0 - well, as long as the last failure step itself succeeded! This is exactly where I've had to add custom code (in every stepdone action) along with using my own status macro to be able to track the real status of the build and not including the failure steps. This is very cumbersome and why my previous suggestion would again save a lot of time and effort.

eg.

sub vbld_StepDone()
Set pmacro = Project.Macros("MYLASTSTEP_STATUS")
pmacro.Value = Step.BuildStatus
end sub

along with an exit step status with a build rule as you describe albeit, using my macro...

%MYLASTSTEP_STATUS% does not equal 0

Note. I actually find it simpler not to use the Exit step as you end up with it after every other step. it's much simpler, in this case, just to skip all subsequent actions using the following build rule on them all:

%MYLASTSTEP_STATUS% is equal to 0

Last edited by mike_laff; 10-21-2006 at 09:13 PM.
Reply With Quote
  #4  
Old 10-25-2006, 09:43 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
Quote:
Originally posted by mike_laff
Hi, thanks for the feedback.

My point here is that subroutine/group steps (the step itself not the steps within) cannot fail as they do nothing. Therefore, is there any point to these failure step settings? I for one, nievely thinking that the subroutine failure settings would do something if the steps within the subroutine failed, wasted hours trying to use these settings. I think it would be helpful to save others the same trouble.
The step could fail if the subroutine being called doesn't exist, an undefined macro is referenced, etc.

Quote:
This does not work if you run any failure steps in the last step. By the time the Exit step gets to evaluate this status, the last failure step will have already modified the %LASTSTEP_STATUS% back to 0 - well, as long as the last failure step itself succeeded! This is exactly where I've had to add custom code (in every stepdone action) along with using my own status macro to be able to track the real status of the build and not including the failure steps. This is very cumbersome and why my previous suggestion would again save a lot of time and effort.

eg.

sub vbld_StepDone()
Set pmacro = Project.Macros("MYLASTSTEP_STATUS")
pmacro.Value = Step.BuildStatus
end sub

along with an exit step status with a build rule as you describe albeit, using my macro...

%MYLASTSTEP_STATUS% does not equal 0

Note. I actually find it simpler not to use the Exit step as you end up with it after every other step. it's much simpler, in this case, just to skip all subsequent actions using the following build rule on them all:

%MYLASTSTEP_STATUS% is equal to 0
You should be able to use FAILSTEP_STATUS in that case.
http://www.visualbuild.com/Manual/systemmacros.htm

Also, as mentioned, if your logic is complex enough to need script events, you should be able to utilize *project-level* script events (i.e., vbld_StepDoneProject) to do it in one place.
http://www.visualbuild.com/Manual/scriptevents.htm
Reply With Quote
  #5  
Old 10-26-2006, 09:20 AM
mike_laff mike_laff is online now
Registered User
 
Join Date: 10-18-2006
Posts: 3
Ok thanks. I can see you're not really interested in feedback.
Reply With Quote
  #6  
Old 10-26-2006, 10:04 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
We actually are. But since we can't implement your feature request tomorrow, I thought you might want to know about options that are available now.


Admin note: Implemented in v6.4
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 10:22 PM.


Copyright © 1999-2023 Kinook Software, Inc.