pre-build action to change target file name doesn't work

[littlesphaeroid]

Since LV2015 it is no longer possible to change a PPL filename after build. My application requires that PPL-based plugins contain the version number as part of the filename ("example 1.2.lvlibp"). I used to handle this with a post-build action.

As a workaround to the new behavior, I created a pre-build action to change the target filename of the build based on the build's version number. The target filename is changed in the build, but the build PPL will have the original file name, not the one modified by the pre-build action. 

I had thought that a pre-build action would allow modification of the build specifications, and that these specs would then be used in the build. This appears not to be the case. Thoughts?

Are there other approaches I can take to set the PPL filename programatically at build time?

[Bob_Schor]

In 2014, I posted a note to allow Pre-Build Actions to modify the Version Information before the build (not unlike what you are trying to do).  I got a lot of gobble-de-gook from NI about how information is cached before the Build, and how this made logical sense, and could be done before a "Pre-Build" action (thereby invalidating the Action).

Pretty soon, NI will say "Not enough people Kudo-ed your Idea, so it was Declined".  As you found, one solution was to "Build Twice", once not to Build, but to set variables after the Build so they would be correct for the subsequent "Pre-Build Action".

I've recently written a routine I call "Build Right" that I now use to Build executables.  It executes any Pre-Build Action, then uses the Build VI function to run the "Build" command on the appropriate Build Spec.  You might giving my Idea a Kudo, and posting a Comment describing your version of the "not-a-Pre" Build Action -- maybe the Folks at NI can fix this illogical situation.

Bob Schor

[littlesphaeroid]

Bob, I'm glad you find this as perplexing as I do. What is a pre-build action for? I use it to check to make sure all VIs (even those called by static reference) are not broken, and a few other checks like that, but modifications to the build instructions are not possible. A pre-pre-build action is required!

Would you mind sharing your Build Right code? That sounds like a decent workaround. It's amazing that one would have to do this at all, but I have no choice unless I am to stay with LV2014. (We're forced to upgrade due to hardware compatibility... grrr!)

[Hooovahh]

Here is one such discussion.

https://forums.ni.com/t5/LabVIEW/Pre-Build-EXE-and-Installer-Set-Version/td-p/3149028

The purpose of that was to set the build version before a built takes place, and then perform the build.  My solution right now is to run the build, have it set the version, then prompt the developer to build again.  The prebuild then generates an error aborting the first build.  The second time it builds without error.  I like this technique better than Bob's because as far as I know his method won't show a progress bar of the build process.

I can see places where pre-build is useful, for things like setting a string constant at the start of a build.  Still I'd prefer if it really worked before the build.  Here is an idea on the idea exchange for this that I think Bob was talking about.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/In-building-executables-allow-Pre-Build-Action-to-mod...

[littlesphaeroid]

Thanks for this idea! Build twice makes sense, if we have no other choice.

[Bob_Schor]

Hooovahh correctly found my Idea Exchange Post, where I "agree to disagree" with the NI guy who argues with me what "Pre-Build" means (I argue it means "Before the Build", not "After you start the Build, but before it really gets into it, in some way undefined ...".  

I also implemented Hooovahh's "Build Twice, Run Once" (hmm, sounds familiar ...) technique, which I think I documented in the comments to my Idea.  The reason this became such a pain was that I was using it with a Project having 5-10 Builds, and wanted to use Build All, but didn't want to baby-sit each Build individually.

So the main thing that Build Right is doing is setting the Build Component of the Version specification to be the current Revision Number for the Project as registered by SVN.  I get this using the VI "SVN Build" that does a System Call on the Project using Tortoise's Subversion Working Copy Revision utility, and use the Get/Set Build Specification Version VIs to update this in the Version Spec (the other elements, Major, Minor, and Patch, are Constants of the Routine).

So the key idea here is the following:

• I gather the "Global Data", the Project Path, the SVN Build, and give the User a choice of picking a Build Spec from a ListBox showing all of the Builds associated with the Project, or allowing the choice "Build All".
• With the Array of Builds (possibly an Array of 1, if chosen from the List Box), update the Build part of the Version, tell the User what we're doing, then use the nice Build.vi to do the Build for me (once).  This works because I do the "Pre-Build Action" before I tell LabVIEW "Do a Build", so it really is "before the Build".

Here's what it looks like:

Bob Schor