[kinook]

Originally posted by CRichardson
I'm evaluating VBP as a possible replacement for FinalBuilder. I can see that both products have relative pros and cons. The main con (for us) against FB is that it doesn't provide a COM interface and this is why we're evaluating VBP. So far, these are my VBP impressions while trying to migrate a FB project to VBP...


1. Help is too superficial
Help often doesn't go into enough detail to actualy help me solve my vbp development questions. However, the fact that I'm grasping for information in the first place probably indicates a problem for what should be a fairly simple to use 'visual build' application.

If you can be more specific, we'll certainly try to rectify that. We've really have tried to provide comprehensive and helpful documentation, and if we've missed things please let us know.

2. Lower level Actions than FB
I'm puzzled why I should be forced to included snippits of macro code in an action to do something as basic as checking that a file exists. FB has a complete action for this - quick and easy to use.

It seems like overkill to use a separate build step for tests like file existence, rather than specifying them inline (usually in a conditional build rule, for instance), but we'll consider creating explicit actions for some common tests.

Note that you can use the Script Editor's Immediate window to assist with such expressions -- open the Step Properties dialog, go to the desired field, type Alt+S (show Script Editor), Alt+I (go to Immediate window), type vbld_FSO.Fi<Enter>("%configfile%"), then press Enter to evaluate the expression or Alt+Ins to insert it as a script expression into the current field.

3. Program constructs like IF / ELSE missing in VBP
Sure, you can kind of reconstruct IF / ELSE using those 'GROUP' actions in VBP but it slows development down a lot. Furthermore, the resulting actions are a devil to debug. I had a situation where the vbld_FSO.FileExists function wouldn't return the correct status unless there was a single variable/macro to represent the file/path instead of a mixture of variable/macro and text. So, this would not work: [vbld_FSO.FileExists("%BuildFolder%\config\config.i ni")] whereas this did work : [vbld_FSO.FileExists(%configFile%)] along with the double quotes assigned as part of the configFile variable\macro (which is the way I saw it done in one of the sample projects). I guess this is fine for those who enjoy pain but I don't.

Visual Build is not really intended to be yet another programming language where if/else, try/catch, looping, and other programming constructs are used a lot. It was actually created to avoid using languages like Perl for automated builds (see http://www.kinook.com/VisBuildPro/features.html). Rather, the idea is to avoid those in most cases, defining the normal chain of build operations, and using failure steps, subroutines, and conditional build rules to handle exceptional cirumstances.

To perform the else for a script expression, add Not at the beginning of the expression; for other comparisons, use the opposite comparison (is undefined/is defined, contains/does not contain, etc.).

Expressions mixing macros and other text are supported (for instance, [vbld_FSO.FileExists("%WINDIR%\system.ini")] works). Please ZIP and send the details (a project or the expression and macro values being used) and we can assist.

4. Complicated options for running projects/steps
FB is a joy compared to VBP in this respect. In FB, it's much more intuitive with simple options to 'run' the project, step, step + children and so on. A small example... In FB, if you select the 'Run' option, it will always run the project cleanly from the beginning unless you have inserted breakpoints. In VBP, the behavior of 'Build'\F7 is quite different and another option has to be selected to reset the project. Not a big deal perhaps but why design an app to be more complicated than it needs to be? Also, I think it's confusing that VBP refers to 'Build' when it should state 'Run'. Logically speaking, I 'run' a 'project' to do a 'build'.

This seems to be mostly differences in terminology. Build (F7) starts at the beginning on initial build, then continues from the next unbuilt step when performed again, rather than starting over from the beginning (useful for continuing from a failure condition or an aborted build). To build all steps from the beginning of the project even if some steps have already been built, use Rebuild (Shift+F7). There are also commands (available on the menu, right-click menu, and via keyboard shortcuts) for building individual steps and groups and to single-step through the build.
http://www.visualbuild.com/Manual/methodsofbuilding.htm

5. No variable inheritance apparent in sub-projects???
Not sure about this as I'm still trying to understand what is or is not available to me in VBP with regard to variable inheritance. Are the project Parameters the only way to pass variable information to a sub-project? Do the parameters work exactly the same in the sub-project as macros/variables? Also, why are variables called 'macros' in VBP???

Temporary and project macros are not automatically inherited by chained projects (global macros are). Temp/project macros that are needed in the child project can be specified on the Parameters tab of the Make VisBuildPro Project action (i.e. Name MYMACRO, Value %MYMACRO), and they will become temporary macros in the child project:
http://www.visualbuild.com/Manual/vbpparameterstab.htm
http://www.visualbuild.com/Manual/macrostab.htm

Also, subroutines are another way to modularize steps within a single project, and subroutine steps have access to all macros in the current project without passing them.
http://www.visualbuild.com/Manual/su...callaction.htm

As far as the use of the term macro instead of variable, VBP macros can be much more dynamic than traditional computer language variables (VBP macros can reference other macros, contain script expressions, etc.), so macro seemed more appropriate (macro has multiple meanings these days, and VBP macros are more like text substitution macros than scripting macros).

6. Generally more difficult to do simple things in VBP than in FB

If you could be more specific about things that are complicated in VBP, we can look into improving that (or at least providing the simplest way to accomplish it).

On the plus side, VBP has a much nicer GUI interface than FB, which is gludgy in comparison. VBP also has the COM interface and what appears to be a well presented Object model. If only VBP could 'borrow' some of the nicer features from FB it would be a near perfect product.