Kinook Software Forum

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

Reply
 
Thread Tools Rating: Thread Rating: 5 votes, 5.00 average. Display Modes
  #1  
Old 03-21-2005, 03:52 PM
pjaquiery pjaquiery is online now
Registered User
 
Join Date: 01-20-2003
Location: Dunedin, New Zealand
Posts: 114
Early exit techniques

I currently throw in JScript to initiate an early exit from a build. This results in the Failure Steps being executed. If I set a macro in the throw process I can test it in the Failure Steps processing and do appropriate stuff (or nothing). However, this is somewhat cumbersome. Is it possible to either perform the equivelent of a catch in the Failure Steps processing (so that the thrown object can be tested), or in some future version provide an Abort or Exit step that allows either a clean exit or a way (set a macro?) of signaling the Failure Steps processing?
Reply With Quote
  #2  
Old 03-21-2005, 06:36 PM
kalons kalons is online now
Registered User
 
Join Date: 03-22-2003
Posts: 13
Could you store the information you need in a temporary macro before throwing? What do you want to be able to test for in the failure steps?

Some enhancements we are considering for the next version are 1) the ability to specify which failure steps to run on failure (instead of always running all steps), 2) the ability to continue the build after performing the failure steps, 3) provide access to the failed step object (either directly or via a unique id) from the failure steps. Would these allow you to accomplish what you want to do?
Reply With Quote
  #3  
Old 03-21-2005, 06:50 PM
pjaquiery pjaquiery is online now
Registered User
 
Join Date: 01-20-2003
Location: Dunedin, New Zealand
Posts: 114
At present I do store information in a temporary macro prior to the throw. However this whole technique requires an explicit throw.

In many of my build projects I check for various macros passed as command line parameters and use those to generate reports and such. I those cases I generally don't want the full build so I exit early using an uncaught throw.

What I'd like would be an Exit step that simply terminates the build at that point.

In other places I test the result of a build step (compile for example) and Abort the build if the compile failed. In that case I'd like to get fail processing performed and set a temporary variable (to indicate what failed). At present I use a small chunk of JScript to get this done.

All of this can be done in some fashion at present; just not in an obvious and clean fashion. An Exit/Abort build step would make the flow of control obvious rather than hidden.
Reply With Quote
  #4  
Old 03-22-2005, 02:53 PM
kalons kalons is online now
Registered User
 
Join Date: 03-22-2003
Posts: 13
The way we deal with selectively building parts of a project is to use build rules (referencing macros passed on the command-line as you mention) on Subroutine Call steps for each part of the build that is optional. Using this technique is straightforward, doesn't require aborting/throwing, and seems cleaner than a "goto" type of action. The VisBuildPro.bld sample demonstrates this technique.

In the case of a compile step failing, aborting of the build should be automatic (with failure steps being built and the build ending without processing steps following the failed step) if the step is not marked to ignore failure.
Reply With Quote
  #5  
Old 03-22-2005, 03:56 PM
pjaquiery pjaquiery is online now
Registered User
 
Join Date: 01-20-2003
Location: Dunedin, New Zealand
Posts: 114
I apologise for dragging this discussion out like this, but... :-)

Yes, I use the subroutine trick too. However the use I have in mind is akin to a switch statement using the Exit/Abort as a break.

A recent example may help. We are adding automated testing and at the end of a successful build we kick of a test by sending email to the test system. The build selects one of two test flavours depending on whether the build itself was initiated "manually" or as part of the overnight build.

Now we want users to be able to kick off a manual test and rather than send some arcane email to the test system we want to set a command line flag on the normal build line. In that case we want just the test to run and to alter the existing build project to the least extent possible. At present I handle that by using the "set variable, throw" technique which requires two steps and a little script, and a test in the failure step processing to suppress failure emails being sent. An Exit in this case would look right clean!

The issue with compile failure is that some of the compilers/installer generators we use don't return a reliable compile success result and the VS compiler can generate bogus link errors that magically go away when the link is retried! In such cases it is more reliable to parse the compiler log file, which we do in any case to provide a summary of compile errors for the failure report email. Again the "set variable, throw" technique is used.

In summary, an Exit/Abort step is a clean and more obvious refinement of a technique that I am already using. It isn't necessary, but, like the "is true" test, it could make projects easier to write and understand.

Ok, I'm out of here!
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 03:04 PM.


Copyright © 1999-2023 Kinook Software, Inc.