Add the legacy product upgrade codes for VeriStand and LabVIEW as substitution variables. Also add trivial substitutions for versions that have proper package names, for convenience when using with the legacy codes. The substitutions are now processed multiple times (until no more substitutions occur), which allows for nesting.
Due to LabVIEW 2017 having an SP1 release (with a separate legacy upgrade code), we can't get away with just defining the upgrade codes per version. Instead, we have to provide a substitution that can handle providing multiple packages, which means handling the version number of those packages as well. This is unfortunately ugly, but it should be easy to remove once LabVIEW and VeriStand 2017 are no longer supported.
For example, Depends: {AUTOVERSION_ni-labview-{labview_version}-x86}, {ni-veristand-{labview_version}} (>= {labview_short_version}.0.0)
Why should this Pull Request be merged?
Enables building nipkgs that depend on versions of LabVIEW and VeriStand which predate NI Package Manager.
By pushing this logic into the build tools, custom devices can easily add a dependency on a given version of VeriStand. This enables building more complex installers, such as having a top level package recommend multiple year versions of a custom device, where the end user will only see the versions corresponding to the versions of VeriStand they have installed.
More specifically, this should allow the VeriStand custom device top-level virtual package to recommend all year versions of the custom devices without installing unusable packages.
What does this Pull Request accomplish?
Add the legacy product upgrade codes for VeriStand and LabVIEW as substitution variables. Also add trivial substitutions for versions that have proper package names, for convenience when using with the legacy codes. The substitutions are now processed multiple times (until no more substitutions occur), which allows for nesting.
Due to LabVIEW 2017 having an SP1 release (with a separate legacy upgrade code), we can't get away with just defining the upgrade codes per version. Instead, we have to provide a substitution that can handle providing multiple packages, which means handling the version number of those packages as well. This is unfortunately ugly, but it should be easy to remove once LabVIEW and VeriStand 2017 are no longer supported.
For example,
Depends: {AUTOVERSION_ni-labview-{labview_version}-x86}, {ni-veristand-{labview_version}} (>= {labview_short_version}.0.0)Why should this Pull Request be merged?
Enables building nipkgs that depend on versions of LabVIEW and VeriStand which predate NI Package Manager.
By pushing this logic into the build tools, custom devices can easily add a dependency on a given version of VeriStand. This enables building more complex installers, such as having a top level package recommend multiple year versions of a custom device, where the end user will only see the versions corresponding to the versions of VeriStand they have installed.
More specifically, this should allow the VeriStand custom device top-level virtual package to recommend all year versions of the custom devices without installing unusable packages.
What testing has been done?
I built the changes on https://github.com/ni/niveristand-routing-and-faulting-custom-device/tree/dev/dependencies and confirmed that the packages have the expected control files. I have not tried installing them due to time constraints.
The output packages are available at
\\nirvana\Measurements\VeriStandAddons\routing_and_faulting_custom_device\ni\export\dev\dependencies\Build 8\.