I purchased Final Builder the previous month and used it now for some time, and there are a couple things I noticed I thought I would share here.
Now those are not so much feature requests as stuff that I am just unsure how to handle best, or where I am wondering if they could be done in a better way. I'm hoping for some ideas from other users, and possibly some feedback from Tate/the FB team as well, of course.
Here it goes.
Variables: Let's say I have this huge build script, and there is this minor, insignificant part of it that uses a File Iterator (or any other iterator), which, of course, requires a variable. Now as far as I can see, like every other variable, this one too needs to be defined globally on a project level. I never feel quite comfortable doing that, though - it seems like minor temporary variables like that don't belong there. Is it just me? Am I missing something?
Hierarchy: The first time I used the "Check if file exists" action, I intuatively attached everything I wanted to happen "If the file exists" to it as subnodes. I only later noticed that the intended usage seems to be to let the action write it's result into a variable (see bullet above). So I wonder, is there any defined/consistent way hierarchy influences the build process, or is it just different from action to action. For example what happens if I add subactions to a comment node? What if I put actions between "catch" and "end", not as subnodes, but on the same level? (Sorry for not trying that myself, but I don't have FB available right now).
make xyz: I would like my build to have different actions, i.e. like a "make build", "make compile", "make setup" etc. Now the best way to do that seems to be using a separate ActionList for each. However, the command line FB doesn't seem to be able to execute only a specific ActionList - you can only pass variables, from what I saw. So I end up having a couple of "if %RequestedAction% == '...'" in the main list, which would then call the appropriate Action List. That works just fine, but I wonder if there is an easier way to accomplish that, maybe.
Hi Michael, (just clarifying up front that I don’t work for FB, I just use it a lot :))
Variables: I agree with you here. You can somewhat mitigate this problem by using action list parameters, which kind of function like local variables. Alternatively, what I do is name any small-scope variables with a leading underscore. So iterators tend to be _file, _dir, _i, etc. Then you can safely reuse the same variables in many places. Hierarchy: Kind of agree. The hierarchy is a little inconsistent. Generally, a child action takes place if the parent “succeeds”. However, options like “do not fail if …” and “ignore failure” make this a bit murky. And of course, with some actions you can reverse the behaviour. You can’t add subnodes to a comment node, but you can add them to an action group, and make that behave like a comment - I do this a lot. If you put actions between catch and end on the same level, you will break your script - FB checks (at the last possible moment…grr) the syntax. Make xyz: There are lots of ways of structuring your FB script at a high level. Sort of depends how similar the different builds are to each other. There’s also the Case statement which may make things a bit cleaner.
I think you pretty much hit upon the biggest weakness in FB - which aren’t very big! Or to look at it differently, the best areas for future development Basically FB is a great scripting language, but is missing a few features to step up to the next level of maturity. It’s debatable whether FB even should have all those complex features like local-scoped variables etc…as programmers we expect them to be there, but do they really need to be? I’ll leave that one up to the FB guys to decide.
what I do is name any small-scope variables with a leading underscore. So iterators tend to be _file, _dir, _i, etc. Then you can safely reuse the same variables in many places.
That's basically what I am doing already. It helps, though I am still not entirely satisfied. I also feel the urge to explain in detail for everyone of those variables where exactly it is used etc. ;)
You can't add subnodes to a comment node,
I tried that in the mean time, it worked for me. They just were never executed.
Well, I guess I can live with a little bit of inconsistency. Things like that are hard to fix/improve too, if you have to maintain backwards compatiblity.
Weird - there’s actually a bug here. You can’t make them by using ctrl+right, but you can by using drag/drop. I thought the intended behaviour was no subnodes to comments.
I’m using 5.0.0.151 btw.
Oh, and incidentally, if you have a “huge build script”, seriously consider breaking it up into smaller pieces. Your variable naming problems will - to an extent - go away.
Thanks very much for these observations, please keep it up. Here are some initial responses:
- Reworking the “Check if File Exists” so it works more like the “If” action is something we intend to do for a future release.
- Generally speaking, an action runs, then it’s child actions run, then it’s sibling action runs. Some actions (like If/Then) skip their child actions if the condition evaluates “False”. Some actions (like Try/Catch) only run their children under certain situations (ie when an error occurs.)
- Messing up the Try…Catch…Finally…End hierarchy should give you a Validation or a runtime error when you try to use the project. If you’ve managed to find a bug where you mess up the hierarchy but don’t see an error, please let us know.
- Ditto the “Children of Comment actions” situation. Do you have steps to reproduce this?
- One of the preferred ways to parameterize your build process is to use a Prompt For Variables (Enhanced) action as one of the first actions in the build process, and have a user enter some parameters there. You can use variables to override these settings if you want to be able to run unattended builds, as well.
- The “Include Project” action gives you the ability to run a particular action list. I’ll talk to the team about adding this functionality to the command line, as well.
- I agree that local variables can seem useful to help you create a well-structured build process. Grouping variables in order to sort them more usefully is on the to-do list. Local variables may be implemented in a future version, but we’re somewhat reluctant because of the extra complexity it brings with it.
thanks for your reponse. Looking forward to future updates.
I just realized I was a bit confused myself about the question of hierarchy, and of course was not able to make it clear want I meant. So here’s what it boils down to. It’s actually a minor thing, but maybe you can clarify.
Is there any difference between the following scripts:
1) # Subversion Add -------# MessageBox
2) # Subversion Add # MessageBox
If I understand correctly, there isn’t. If “Subversion Add” fails, the MessageBox will not be shown, if it succeeds, it will. Why then is it possible at all to add subnodes here? Is it intended as an additional option to structure a build script? If so, would that be a recommended usage pattern?
There’s a difference if the Subversion step is marked “Ignore failure”. In that case, the Messagebox step will only run if it succeeds.
Otherwise, the difference is purely aesthetic. I’ve toyed with using the hierarchy this way, but IMHO it’s a waste of a good hierarchy. I use Action Groups to really structure my scripts, with the added advantage that you can rename them to something meaningful:
Check out project files <-- action group -Subversion checkout -If prev action failed –Messagebox -Subversion checkout other files -If prev action failed –Messagebox
The other advantage is that you can collapse groups. Though running the script tends to uncollapse them again…
As Steve says, there’s some small differences. The one advantage to 1) though is that they are grouped so that they can be disabled/enabled together - either in the UI or using the condition property at runtime.
> Though running the script tends to uncollapse them again…
but the original state should be returned once the build finishes…
Basically FB is a great scripting language, but is missing a few features to step up to the next level of maturity. It’s debatable whether FB even should have all those complex features like local-scoped variables etc…as programmers we expect them to be there, but do they really need to be? I’ll leave that one up to the FB guys to decide.