[Discuss] Build Script

[jgcode]

Name: Build Script

Submitter: jgcode

Submitted: 13 Nov 2009

File Updated: 03 Jan 2011

Category: *Uncertified*

LabVIEW Version: 8.6

License Type: BSD (Most common)

Build Script v1.1.0

Copyright © 2009, Jonathon Green; JGCODE

All rights reserved.

Author: Jonathon Green

LAVA Name: jgcode

Contact Info: Contact via PM on lavag.org

LabVIEW Versions:

LabVIEW 8.6

LabVIEW 2009

Dependencies:

jki_lib_state_machine >= 2.0.0

jki_rsc_toolkits_palette >= 1.1

oglib_array >= 2.0

oglib_appcontrol >= 2.0

ogrsc_dynamicpalette >= 0.2

oglib_error >= 2.0

oglib_file >= 2.5

Unit Test Framework (optional)

Description:

Contains a build script for a LabVIEW Project. Use a build script in your development to automate the task of, and avoid errors when, creating deliverables. A sample project is included that creates an application, installer then archive (.zip) for a project. This build script supports the new 9.x build format by building the specs in a high level temp folder (e.g. C:\dist) to minimise errors occurring from the OS exceeding maximum number of characters in path. NI's Unit Test Framework (UTF) is supported or code can be added for other Unit Test APIs (see Unit Test Framwork.png for demo code).

Installation and instructions:

The dist folder contains build.vit and a library (.llb) of support code. See Examples section on how to use code.

Examples:

1. Open example\Project.lvprj

2. Open and run build.vi, VI should complete execution with no errors

3. Once build script has completed explore example\dist to view all builds (application, installer, zip)

4. Unzip zip folder and install application

5. Run the application

6. "Build Works!" dialog should appear to indicate sucessful build

7. Reuse script

a. Use build.vit as starting template for project

b. Edit the project details on the block diagram to match to new project

Known Issues:

No Known Issues

Acknowledgements:

Justin Goeres (JKI)

Joel Spolsky

JKI (JKI State Machine)

OpenG

ICON Technologies

Version History (Changelist):

1.1.0 2009 11 15

[Fix] Code saved to LabVIEW 8.6 on request from LAVA member. Unit Test Framework VIs were removed due to build issue.

[Fix] SubVIs added to a .lvlib within a .llb.

1.0.0 2009 11 14

[Feature] Initial release of the code (LabVIEW 2009).

License:

BSD

Support:

If you have any problems with this code or want to suggest features:

please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and

search for the Build Script support page.

Distribution:

This code was downloaded from the LAVA Code Repository found at lavag.org

Click here to download this file

[jgcode]

Imitation is the sincerest form of flattery - Charles Caleb Colton (1780-1832)

Firstly I would like to say that I did not originate this idea, I first saw it posted on the JKI Blog by Justin Goeres. However, no code was posted, so I took what was there (GUI screenshot, BD screenshot, explanations etc..), said thank you, and came up with this. Of course I read Joel on Software and other books on (java) build scripts and seen other posts discussing LabVIEW build scripts etc.. but I wanted to make the above point up front as it is going to be very similar, but it was a great blog post about a great idea with a great example and I decided to implement it, use it and share it - with LAVA. So I hope its all ok. Thanks for listening.

Below are some notes on the code:

Since I was going to make this a template (.vit) a put a bit of extra GUI code in it. I wanted a clear visual sign when I came back to my desk that this thing had worked.

Or something had happened to make it fail. I also wanted to know the time it takes to build the project. With classes and libraries the build time can blow out from seconds to minutes (over 10) for some projects. Although 2009 seems much faster than 8.6. So I added another thread for a simple timer.

This script has support for 9.x builds. I found straight away I would get errors if my src code and dist folder where deeply nested in the folder hierarchy on the OS. 9.x solved the ugly build problem of files outside the exe, but it left me with a sour taste as my build frequently stopped due to error. This script solves the problem by transparently build in other folder (e.g. D:\dist) then coping these back to the Project. The only catch is (because reading the file XML tags in the project looks daunting) the 9.x Root path must match the start of the path in the build spec. Because I use the same location D:\dist I add a Project folder for each Project e.g. D:\dist\Project. the all the builds get located under here e.g. D:\dist\Project\application or D:\dist\Project\installer etc..

The architecture of the template is implemented using the JKI State Machine. Which is great for building GUI's quickly.

If you want to copy then edit this build for other projects (I had it as a .vit) then you will need to update the Project Details. The folder structure is hard-coded as this is a standard I use. All folders are relative to the project though. And there are some example files copied to the zip (for the creation of a CD).

I use NI's UTF a lot and this can run tests in the Project automatically. It can even decide to kill the build if tests fail. It is disabled in the distribution in case it is not installed.

Other

The application build Version can be auto-incremented and the installer Version is matched to it.

Support code used can be found in ..\lib. The subVIs are from libraries I use. You may find some reuse options in there.

I have been playing around with an AUTO feature that essentially defines constants for the GUI and therefore this script could be called by something else (e.g. as subVI) for an automated build (e.g. nightly).

I am looking doing the following in the future

Converting the .zip to an ISO so it's ready to burn; Archiving zip if its a release to server, SCC actions,

This code is a start and I would love to see what other people are doing and add to this over time.

Hope you enjoy it.

[jcarmody]

Justin's blog post CHANGED MY LIFE!  I re-wrote my own interpretation of this earlier this week (I had made an ugly version after reading the post and wanted one that could be shared), but didn't go as far as you did.  I can't tell how far you went, however, because I don't have LabVIEW 2009 yet.  Can you save it back to 8.6 (at least)?  Short of that, could you show me how you managed the timer?  My timer keeps time but the interface frequently hangs/freezes when the builder is running.

[jgcode]

Justin's blog post CHANGED MY LIFE!  I re-wrote my own interpretation of this earlier this week (I had made an ugly version after reading the post and wanted one that could be shared), but didn't go as far as you did.  I can't tell how far you went, however, because I don't have LabVIEW 2009 yet.  Can you save it back to 8.6 (at least)?  Short of that, could you show me how you managed the timer?  My timer keeps time but the interface frequently hangs/freezes when the builder is running.

Hi Jim

Yes, it was a great blog post! It's 2am here, but I will have a look at this tomorrow. I have just upgraded to Windows 7, so I don't have everything installed yet. But I will try to put on 8.6.1 if I have the time (delayed pay-per-view tomorrow) . It should back save ok as the same XML tags are used in 8.6 and LabVIEW 2009. Don't know about 8.5 and I know 8.2 is different.

As you can see from the block diagram, the timer just runs in another thread however, using the NI Build VIs the updating gets blocked (maybe the build runs as a high priority ?? - someone from NI may be able to comment). So it periodically updates. Thats ok cause the idea is I can leave it running and go away from the desk, I really just want to find the total duration.

What else did you add? Are you able to share code or any screenshots?

Cheers

JG

[jcarmody]

[...] the timer just runs in another thread however, using the NI Build VIs the updating gets blocked (maybe the build runs as a high priority ?? - someone from NI may be able to comment). So it periodically updates. Thats ok cause the idea is I can leave it running and go away from the desk[...]

It works, but it's not as nice as I'd like it.

What else did you add? Are you able to share code or any screenshots?

I don't have as much as you have.  Mine builds the executable and installer then closes LabVIEW and launches the installer.  I want to add a function to set file permission on the ini files to restrict editing to admins.  I'll be able to post it Monday, but it's not very fancy.

[jgcode]

It works, but it's not as nice as I'd like it.

I don't know if there is a way around this? If LabVIEW itself it blocking execution of the second thread running (or the UI updating) then I don't know if there is a workaround.

I don't have as much as you have.  Mine builds the executable and installer then closes LabVIEW and launches the installer.  I want to add a function to set file permission on the ini files to restrict editing to admins.  I'll be able to post it Monday, but it's not very fancy.

Thats a cool idea to run the installer - (assuming its an NI Installer you are using??) are you able to somehow respond to the prompts so it can install automatically - that would be cool!

Which ini files are you talking about? Are these the "settings" of the application that you own? Or the default .ini file created by LabVIEW?

Look forward to seeing it Monday

[jgcode]

Can you save it back to 8.6 (at least)?

Hi Jim

I have saved it back to 8.6 and tidied up the release a little. I had to take out the Unit Test Framework VIs for now - I will have another look tomorrow after work. I have included a VI with the disabled case at the moment so you all you have to do is just paste it in.

I will create a OpenG package for this next in the next release as well.

Hope you like it!

Cheers

JG

UTF(86).vi

[LabVIEW8.6]

[jgcode]

I should also mention if everything goes well you should see this

[jcarmody]

[...] Thats a cool idea to run the installer - (assuming its an NI Installer you are using??) are you able to somehow respond to the prompts so it can install automatically - that would be cool!

 

Yes NI installer, no automatic prompt responses.

Which ini files are you talking about? Are these the "settings" of the application that you own? Or the default .ini file created by LabVIEW?

Application settings.  I use configuration files to make the system flexible when I'm working on it, but I want less flexibility when it's working in production.

Look forward to seeing it Monday

 

One-click build-n-install.zip

[jgcode]

 

Yes NI installer, no automatic prompt responses.

Application settings.  I use configuration files to make the system flexible when I'm working on it, but I want less flexibility when it's working in production.

 

Hey Jim thanks for posting - I am checking it out now over lunch.

May I ask what project SmokeCal is about?

The name sounds very Bondish

[jcarmody]

May I ask what project SmokeCal is about?

It's a system for calibrating smoke detectors.

I am checking it out now over lunch.

I don't use forums when I'm supposed to be working, either.  

[jgcode]

I don't use forums when I'm supposed to be working, either.  

It was just in case the boss was reading it

But I have to say; all these forums help me with my work as well, I don't think I would be as productive, or inspired, without them. But I have to be careful, I could easily chew through an hour without even noticing!

[jcarmody]

But I have to say; all these forums help me with my work as well, I don't think I would be as productive, or inspired, without them.

My sentiments exactly.

[jgcode]

My sentiments exactly.

Well, heres cheers to LAVA

[Jim Kring]

Great work, jgcode! Thanks for sharing this.

My only complaint (I'm only joking, really) is that you're not using VI Tester

Cheers,

[jgcode]

Great work, jgcode! Thanks for sharing this.

My only complaint (I'm only joking, really) is that you're not using VI Tester

Cheers,

Thanks Jim much appreciate - and you guys as JKI inspired this one - so thank you too!

You will be happy to know I had to take out the UTF because I could create a dist with it in (I have to follow this up to check whether the error is a bug or not).

Anyways, I think VI Tester API will fit in there quite nicely.

[dannyt]

Hi Jim

Yes, it was a great blog post! It's 2am here, but I will have a look at this tomorrow. I have just upgraded to Windows 7, so I don't have everything installed yet. But I will try to put on 8.6.1 if I have the time (delayed pay-per-view tomorrow) . It should back save ok as the same XML tags are used in 8.6 and LabVIEW 2009. Don't know about 8.5 and I know 8.2 is different.

JG

Hi,

I have been playing with your build script and I really like the potential of it.

Unfortunately our code base is written in LabVIEW 8.2 and I have been playing around trying to get the build script working in 8.2, so this is just a quick not to anyone who may be interested, the build script CAN be run when saved back to LabVIEW 8.2.1, but the project must be closed for it to work.

It appears in LabVIEW 8.2.1 the call to AppBuilder\BuildTargetBuildSpecification.vi will fail with an error 1025 if the project is open. However close the project and the call works.

Extra note in LabVIEW 8.2.1 if you open the project then open your build.vi and close the project, the build.vi VI will also close. So first ensure that your project is closed, open your build.vi and run it.

cheers

Dannyt

[jgcode]

Hi,

I have been playing with your build script and I really like the potential of it.

Unfortunately our code base is written in LabVIEW 8.2 and I have been playing around trying to get the build script working in 8.2, so this is just a quick not to anyone who may be interested, the build script CAN be run when saved back to LabVIEW 8.2.1, but the project must be closed for it to work.

It appears in LabVIEW 8.2.1 the call to AppBuilder\BuildTargetBuildSpecification.vi will fail with an error 1025 if the project is open. However close the project and the call works.

Extra note in LabVIEW 8.2.1 if you open the project then open your build.vi and close the project, the build.vi VI will also close. So first ensure that your project is closed, open your build.vi and run it.

cheers

Dannyt

Hi Dannyt

I just saw this sorry! (subscribe to updates wasn't checked!)

Glad you like the potential of the script, it really can simplify things.

I have one for creating packages e.g. creates the correct size icon, updates dependency list from .vipc file, builds code using NI BUILDER and then the package using OGPB, then zips it up with all the LAVACR stuff (readme, examples, .vipc file etc...).

It just removes human errors during that process, so running the end product is much more reliable.

To confirm your post - the code is actually in LV8.2 for the Project API VIs (and most other internal libs).

But I really only use it for LV2009 personally.

To add in support the Project Tags need to be updated when they change between versions.

And I have only tested the Tags for LV2009.

I choose LV8.2 because that what most of my reusable code is in - and support for LV8.2 if I ever wanted it.

I upgraded the Project API package over this weekend as part of abstracting functionality in the script for reuse-ability.

Even things such as resolving the output path of the dist or exe is different between 8.2 and LV2009 (discussion of this is related to Ton's Post here)

So there is a bit more work to support all versions.

Have you implemented a scripting process in your work?

Do you have any feedback or examples to add?

Look forward to hearing what you've done.

Cheers

-JG

[dannyt]

Have you implemented a scripting process in your work?

Do you have any feedback or examples to add?

Look forward to hearing what you've done.

Cheers

-JG

Hi JG,

We do have a automated build system here and have had one for 2 years or so. Until this last month or so it was all based around the openG builder, until I looked at your code and found BuildTargetBuildSpecifications VI. So I have only really used from the code the case for building executables and built my own code around it.

On our executables we have a 'Help About' VI that we populate with things like build time, who built it, our ClearCase Configuration Specification and label. So most of the code I have added is my own ClearCase control VI's to check files out, update info and after the build to tidy all this up again. also I create a BOM of my builds.

I am really please with the results of this and must pass on my thanks to you in showing my another way to do this.

I must admit I am quite sad as I have after about 2 years finally abandoned the OpenG builder. But I have now decreased my build times from well over half an hour to around 5 minutes and my final built executable is around 6M smaller than it used to be. I do as a result loose the OpenG VI rename/ mangle options during build, but as all our software stays internal it was part of the openG builder I never used.

Dannyt

[jgcode]

I am really please with the results of this and must pass on my thanks to you in showing my another way to do this.

Thats great news, it is rewarding to hear that. This place is great for learning new stuff, I don't know where I'd be without LAVA/Internet. Definitely behind the 8-ball.

I must admit I am quite sad as I have after about 2 years finally abandoned the OpenG builder. But I have now decreased my build times from well over half an hour to around 5 minutes and my final built executable is around 6M smaller than it used to be. I do as a result loose the OpenG VI rename/ mangle options during build, but as all our software stays internal it was part of the openG builder I never used.

I haven't ventured down that track. Have heard some feedback from Daklu thats its a bit complicated to learn but pretty neat.

NI works fine for me. But I still wouldn't mind taking a look.

We do have a automated build system here and have had one for 2 years or so. Until this last month or so it was all based around the openG builder, until I looked at your code and found BuildTargetBuildSpecifications VI. So I have only really used from the code the case for building executables and built my own code around it.

On our executables we have a 'Help About' VI that we populate with things like build time, who built it, our ClearCase Configuration Specification and label. So most of the code I have added is my own ClearCase control VI's to check files out, update info and after the build to tidy all this up again. also I create a BOM of my builds.

Thanks for replying with what you do.

I am part way through implementing the following (which will be dependent on the project):

Check Out/In Project with updated Build Versions (I use Perforce)

Download installers (drivers, support software etc...) and extract files (zips) when building a Full Installer (usually as a CD)

Convert .bat files to exe (I have to see if this is possible with 3rd Party Software)

Create ISO image (For CD Installers) (have command line interface for my burning app so this should be fine)

Output text or image of Version for CD Label (I would like to automate this but I don't think my CD Label app has any hooks)

Move deliverable (Zip/ISO etc...) to Server

Label src code after save and build

And off course all this will be reusable.

A bit of work, but it is definitely worth it.

Also what is BOM (Bill Of Materials?) and how do you use it in your workflow?

[dannyt]

Thanks for replying with what you do.

I am part way through implementing the following (which will be dependent on the project):

Check Out/In Project with updated Build Versions (I use Perforce)

Download installers (drivers, support software etc...) and extract files (zips) when building a Full Installer (usually as a CD)

Convert .bat files to exe (I have to see if this is possible with 3rd Party Software)

Create ISO image (For CD Installers) (have command line interface for my burning app so this should be fine)

Output text or image of Version for CD Label (I would like to automate this but I don't think my CD Label app has any hooks)

Move deliverable (Zip/ISO etc...) to Server

Label src code after save and build

And off course all this will be reusable.

A bit of work, but it is definitely worth it.

Also what is BOM (Bill Of Materials?) and how do you use it in your workflow?

Wow sounds like you have set yourself a big but very impressive target

Yes a BOM is Build Of Materials, it tend to just be used for a QA satifaction / audit point of view. It can be useful to see easily what files have change between build as it included's the source control system version info for each file.

Danny

[jgcode]

Wow sounds like you have set yourself a big but very impressive target

I like to think big

Its not that hard. I have already done some of it and it works sweet.

The other ideas I have had for a while.

It just about getting the time.

Yes a BOM is Build Of Materials, it tend to just be used for a QA satifaction / audit point of view. It can be useful to see easily what files have change between build as it included's the source control system version info for each file.

Ok, cool. So you request this from your SCC then create a text file or HTML document or similar?

Out of interest - do you have an example document of what this looks like?

Cheers

JG

[dannyt]

Ok, cool. So you request this from your SCC then create a text file or HTML document or similar?

Out of interest - do you have an example document of what this looks like?

Cheers

JG

example BOM file

-------------- ClearCase Build Info (Build Start) -----------------

ClearCase Build View : petes-dev-ats-814

ClearCase Config Spec :

element * CHECKEDOUT

element * /main/dev-ats-814/LATEST

element * /main/B591-ATS-2009NOV24 -mkbranch dev-ats-814

element * /main/0 -mkbranch dev-ats-814

create_message_event.vi,P:\testTeam\ATS\Projects\test_exec_framework\user_events\create_message_event.vi,\main\1,

create_exit_event.vi,P:\testTeam\ATS\Projects\test_exec_framework\user_events\create_exit_event.vi,\main\1,

run_sequence_data_type.vi,P:\testTeam\ATS\Projects\test_exec_framework\general_type_defs\run_sequence_data_type.vi,\main\1,

update_symbols_run.vi,P:\testTeam\ATS\Projects\Sandpit\update_symbols_run.vi,\main\1,

Open File+.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Utility\file.llb\Open File+.vi,CC PATH NOT FOUND,file.llb

kHz-MHz.vi,P:\testTeam\ATS\Projects\Sandpit\kHz-MHz.vi,\main\1,

NI_MAPro.lvlib:ma_Check for Equality with Precision.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Check for Equality with Precision.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Range Check with Precision.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Range Check with Precision.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Limit Test Outside.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Limit Test Outside.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Limit Test Inside.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Limit Test Inside.vi,CC PATH NOT FOUND,mamon.llb

As you see starts with the ClearCase Config Spec used for the build then lists all the files used in build.

Each line is comma separated look like

VI name, full filepath, ClearCase extended path info (if a ClearCase object), llb name if VI is in a llb.

[jgcode]

example BOM file

-------------- ClearCase Build Info (Build Start) -----------------

ClearCase Build View : petes-dev-ats-814

ClearCase Config Spec :

element * CHECKEDOUT

element * /main/dev-ats-814/LATEST

element * /main/B591-ATS-2009NOV24 -mkbranch dev-ats-814

element * /main/0 -mkbranch dev-ats-814

create_message_event.vi,P:\testTeam\ATS\Projects\test_exec_framework\user_events\create_message_event.vi,\main\1,

create_exit_event.vi,P:\testTeam\ATS\Projects\test_exec_framework\user_events\create_exit_event.vi,\main\1,

run_sequence_data_type.vi,P:\testTeam\ATS\Projects\test_exec_framework\general_type_defs\run_sequence_data_type.vi,\main\1,

update_symbols_run.vi,P:\testTeam\ATS\Projects\Sandpit\update_symbols_run.vi,\main\1,

Open File+.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Utility\file.llb\Open File+.vi,CC PATH NOT FOUND,file.llb

kHz-MHz.vi,P:\testTeam\ATS\Projects\Sandpit\kHz-MHz.vi,\main\1,

NI_MAPro.lvlib:ma_Check for Equality with Precision.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Check for Equality with Precision.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Range Check with Precision.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Range Check with Precision.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Limit Test Outside.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Limit Test Outside.vi,CC PATH NOT FOUND,mamon.llb

NI_MAPro.lvlib:ma_Limit Test Inside.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Limit Test Inside.vi,CC PATH NOT FOUND,mamon.llb

As you see starts with the ClearCase Config Spec used for the build then lists all the files used in build.

Each line is comma separated look like

VI name, full filepath, ClearCase extended path info (if a ClearCase object), llb name if VI is in a llb.

Thanks Kudos