NI Package Manager (NIPM)

cancel
Showing results for 
Search instead for 
Did you mean: 

Dependency on LabVIEW RTE

With LabVIEW 2017 and above, EXE's and PPL's can be built with settings to "allow future versions of LabVIEW to load this...". This is an awesome feature. When you make a package in LabVIEW, it currently adds a dependency to the version of the LabVIEW RTE that you are using to build. We often build our PPLs or EXE's in 2019, but support a plethora of customers from 2019 up to 2023 using the same PPLs/EXEs.

 

We don't want to force them to have to install LabVIEW 2019 when our code has been tested and works perfect in 2023 for example. Or we don't want them to have to install LabVIEW 2019, if they already have a newer version installed.

 

Is there any way to control the dependencies for a packages with the name "ni-labview-[YEAR]-runtime-engine" and say it's required, but only for 2019+ so it can look for any version. Or do we have to do a Depends: ni-labview-2019-runtime-engine | ni-labview-2020-runtime-engine | ++ up to 2023, and rebuildi every year to include the new version.

0 Kudos
Message 1 of 4
(1,171 Views)

I'm not sure what year they started this, but recent LV RTE packages all seem to now provide name "ni-labview-runtime-engine" -- so you can just depend on that name. That name does also includes the version, so you could do "ni-labview-runtime-engine (>= 22.0), for example. What this means is that any version of the LV RTE installed that meets your minimum version would satisfy that dependency.

You could check this by looking at the control file for the LV RTE package, and look for the Provides: attribute.

0 Kudos
Message 2 of 4
(1,126 Views)

Looks like 2021 was the first year they added that provides from what I can see. So I could do something like the following I believe.

 

ni-labview-2019-runtime-engine | ni-labview-2020-runtime-engine | ni-labview-runtime-engine (>= 21.0)

 

Although I'd have to do this post build since LabVIEW packages don't support this OR operation it looks like (or selecting Provides instead of the package name itself).

0 Kudos
Message 3 of 4
(1,117 Views)

Yes, that sounds about right!

0 Kudos
Message 4 of 4
(1,094 Views)