Run build specifications programmatically for different LV versions

[andrea.angeloni.alfamation]

Dears,

company LV code must be supported for several LV versions at the same time. Code is supplied as dll or source distribution.

Part of current flow for deploy is:

 - create a build specification, with different target directory, for each needed LV version

 - open needed LV version, run suitable build specification, close without saving

Thus I have to open each time the development environment to run the correct build specification.

At the moment I must support LV 2013, 2015, 2016 both x86 and x64 platforms. It means that each build I must open six different IDEs.

Thus question is: is there a way to programmatically do this boring and no-added-value job?

Thanks for your precious help,
Andrea

[Alexander_Sobolev]

The build that you need to install, is it always the same, does only target directory differ?

Then you can configure LV installer to install it to fixed directory and write an exe that runs after installation, lists available LV versions, asks where to deploy and copies files to target dirs.

Do you want to automate building of these installers to avoid recompiling for different version on target? It can be done.

Make the file that initiates the build when open (C:\aa.vi) (use Application control -> Application builder -> Build.vi).

If you call aa.vi from correct version, I guess it will use correct version to build: C:\Program Files (x86)\National Instruments\LabVIEW 201X\Labview.exe C:\aa.vi

[andrea.angeloni.alfamation]

Alexander,

thanks for your answer. Indeed, I'm working in the direction you pointed: a VI that runs the build specification is called with "correct" LV version, taking as parameters the project file name and the build specification name.

What I don't like is that to have a VI accept command line parameters it must be configured as "Run when opened" and it must be executed starting from LV not started, otherwise parameters are not correctly passed. It is working, but definitely far away from elegant.

I was expecting something like traditional text programming IDE, where you set the build target and then the software finds his way alone.

Andrea

[Bob_Schor]

Andrea,

     One very big difference between LabVIEW and many other languages is that each LabVIEW Version is "unique" and "specific".  If you need code to be built with multiple versions of LabVIEW (say, 2012, 2014, and 2016), then you need to maintain the "basic" code base in LabVIEW 2012, or otherwise face the headache of keeping three Versions that need to be "strictly" opened with the correct LabVIEW version (itself something of a potential nightmare -- definitely use some form of Version Control System) all similarly revisioned.

     An alternative is to keep only the most current version, upgrading the basic 2012 code to 2016.  When you deploy it on your other machines, you simply need to ensure that they each have the appropriate 2016 RTE, which you can probably do by building an Installer (confession -- I've never built an Installer, but I have hand-installed appropriate RTEs on my target machines).

Dealing with 32 and 64-bit systems also does not sound pleasant.  Not only do you have to consider the OS on the target (32 or 64-bit), but you might potentially also need to consider the "bittedness" of LabVIEW (though I'm pretty sure you can't build a LabVIEW-64 executable that runs on 32-bit Windows).

Perhaps, when all is said and done, if you really do have to maintain six independent builds, you might need to keep doing it manually.  See if you can simplify/consolidate ...

Bob Schor

[andrea.angeloni.alfamation]

Ciao Bob,

thanks for your feedback. My company's product are supplied as dll or source distributions. Dll can be managed as you suggest, with LRTE, but source distributions, typically deployed in vi.lib, must all be in the correct LV version. At the moment we mantain code in the oldest supported version, and run build specifications from all needed other versions. We really need all of them, because we must provide bug fixes for older systems, but keep implementing new products, one major feature being in 64bits instead of 32.

Regards,

Andrea