06-06-2023 09:36 AM
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.
06-07-2023 10:50 AM - edited 06-07-2023 10:53 AM
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.
06-07-2023 11:20 AM
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).
06-08-2023 01:07 PM
Yes, that sounds about right!