Multiversion Package for (open)GDS

[MaartenSker]

Hello, As active users of the open GDS package, we were trying to distribute it through our own VIPM repository. Unfortunately because all versions of the package are distributed from the GitHub page for each version separately it is not possible to do that.

I was wondering. Why is the package of the NI GDS available for all versions greater then 2014, and are all version on the GitHub version specific?

After some "hacks" on the existing packages on Github, to try and make them multiversion.I was unsuccessful trying to add missing items in the spec file inside the VIP.

Is there a possibility to get a VIPB for the package or something to generate a package for all LabVIEW versions greater than 2014 for example? To keep it more easily maintainable inside our team.

[MikaelH]

FYI, the source of the OpenGDS is in 2014, and the build process just re-compiles the code for all other versions.

So to make it easy for you, can you just use the 2014-32 bit version, and have VIPM do the re-compile of all VIs after installation.

I guess you need to change that flag in the VIPM spec file to allow it to recompile the source.

The only reason I've pre-compiled all the different version is that it takes VIPM 30 minutes or so to do the recompilation.

[MaartenSker]

Thanks for the reply.

I actually did make a mistake in trying to adapt the spec.

After an edit on the 2014-32bit VIP, and set the Exclusive_LabVIEW_Version from "=2014" to ">=2014" i was able to install on 2015. But i also set the parameter of "skip mass compile after install from "TRUE" to "FALSE".

This indeed took the VIPM about 9 minutes to install the package including the mass compile. But afterwards in the labview restart the GDS asked me to re-compile its code again. This again took 7 min.

Is both necessary? and if not is one preferred above the other?

[MikaelH]

When the the GDS init VI(GOOP_LVClass_Global_Init.vi) first runs, it checks the hidden property "CompileTime" of the itself.
If that is zero, it means (I think) that it was pre-compiled, if not I'll show the Re-compile dialog:

LabVIEW 2016\resource\Framework\Providers\Open_GDS\SubVIs\GOOP_RecompileDialog.vi

Maybe VIPM don't successfully recompile all VIs.

[Jim_Kring]

---

@MikaelH wrote:

When the the GDS init VI(GOOP_LVClass_Global_Init.vi) first runs, it checks the hidden property "CompileTime" of the itself.
If that is zero, it means (I think) that it was pre-compiled, if not I'll show the Re-compile dialog:

LabVIEW 2016\resource\Framework\Providers\Open_GDS\SubVIs\GOOP_RecompileDialog.vi

Maybe VIPM don't successfully recompile all VIs.

---

Hi Mikael, It seems that the combination of configuring the package to tell VIPM to NOT mass compile on installation and then have GDS do its its own mass compile when it is first loaded, then that should do the trick. There would be a lot of value in having only a single package file build/deploy/install. I'm happy to help figure this out.

[MikaelH]

I agree, if I only need to build one package that would save me some time.
At the moment all version are the same, that was not true when I had to support LV2012.
The recompilation takes quite some time so that's why I recompile them so the user don't need to.
If you can speed up VIPMs recompile time that would be good.
How does NI's Package Manager handle re-compiling VIs?

[Jim_Kring]

---

@MikaelH wrote:

I agree, if I only need to build one package that would save me some time.
At the moment all version are the same, that was not true when I had to support LV2012.
The recompilation takes quite some time so that's why I recompile them so the user don't need to.
If you can speed up VIPMs recompile time that would be good.
How does NI's Package Manager handle re-compiling VIs?

---

Hi Mikael.  I was going to propose we use the self-mass-compile feature within OpenGDS, the first time it starts up, if the VIPM compiler feature takes too long for most users. Is that still built into the pre-packaged versions of GDS, or would you need to do a special build?

Yes, it would be nice to improve the mass compile speed, but not sure if it's easily possible.

[MikaelH]

The Compile step is already in there.
LabVIEW 20XX\resource\Framework\Providers\Open_GDS\SubVIs\GOOP_RecompileDialog.vi
It gets called from this VI:
LabVIEW 20XX\resource\Framework\Providers\Open_GDS\GOOP_LVClass_Global_Init.vi

What happens the first time you start LV, it will take some time for LV to start, since it needs to recompile all VIs.
That is needed for the IDE to start.
So if we would publish OpenGDS on ToolsNetwork, the 2014-32 bit version should be enough.
But maybe we should (almost) force the user to press recompile!?!?

[Jim_Kring]

---

@MikaelH wrote:

The Compile step is already in there.
LabVIEW 20XX\resource\Framework\Providers\Open_GDS\SubVIs\GOOP_RecompileDialog.vi
It gets called from this VI:
LabVIEW 20XX\resource\Framework\Providers\Open_GDS\GOOP_LVClass_Global_Init.vi

What happens the first time you start LV, it will take some time for LV to start, since it needs to recompile all VIs.
That is needed for the IDE to start.
So if we would publish OpenGDS on ToolsNetwork, the 2014-32 bit version should be enough.
But maybe we should (almost) force the user to press recompile!?!?

---

That's great.

I would do the following (for the recompile dialog/process):

(1) automatically start the recompile process at startup (don't even put up an OK button, just start the recompile, but make sure the recompile progress tell the user what's happening and why) and then

(2) add a "cancel" button (but name the button "Recompile Later") to the recompile process that allows the user to skip the rest of this recompile process until the next time they start the IDE.