OpenG array 6.0.1.20 update will force all my VIs using it to recompile

[LaurentCoherent]

 

Hi,

I updated recently all my OpenG packages from VIPM directly (OpenG array 6.0.1.20 with LabVIEW 2020). Since I'm using them a lot, I thought it was the correct move. However, by opening afterwards VIs using openG, they got the start and are forced to recompile. Since I'm using Gitlab, I would like to avoid a commit on all my projects because of that.

Do you have a better solution? Am I doing something wrong?

thanks and regards,

Laurent

[Rolf Kalbermatter]

The change to "librarize" all OpenG functions is a real change in terms of requiring any and every caller to need to be recompiled. This can't be avoided so I'm afraid you will either have to bite the sour apple and make a massive commit or keep using the last OpenG version that was not moved to libraries (which in the long run is of course not a solution).

[iannicholson]

What about purchased libraries that depend on OpenG, and may or may not be maintained anymore? I guess I'll have to discontinue using these libraries if I need to upgrade OpenG 😔

[Rolf Kalbermatter]

7 hours ago, iannicholson said:

What about purchased libraries that depend on OpenG, and may or may not be maintained anymore? I guess I'll have to discontinue using these libraries if I need to upgrade OpenG 😔

Did you run into any specific problems in that respect? If those commercial libraries are provided with diagram, even if they are password protected or hidden behind a license, they should load and recompile fine. If the library is not provided with diagram, it is pretty much useless anyways, as you can not change LabVIEW versions at all.

What problems have you seen? What LabVIEW versions? Or is this more an academic exercise to complain about something? I don't endorse the libraryfication of existing libraries just for the sake of making them a vilib. But it can be useful when trying to do componentized deployment through packed libraries. But your argument kind of sounds like a constructed argument, unless there is a specific problem that I'm not aware of.

Edited Wednesday at 08:27 AM by Rolf Kalbermatter

[ShaunR]

On 4/23/2024 at 8:52 AM, Rolf Kalbermatter said:

The change to "librarize" all OpenG functions is a real change in terms of requiring any and every caller to need to be recompiled. This can't be avoided so I'm afraid you will either have to bite the sour apple and make a massive commit or keep using the last OpenG version that was not moved to libraries (which in the long run is of course not a solution).

Wasn't separate compiled code meant to resolve this issue? Is it just that some of the VI's were created before this option and so still keep compiled code?

[Rolf Kalbermatter]

27 minutes ago, ShaunR said:

Wasn't separate compiled code meant to resolve this issue? Is it just that some of the VI's were created before this option and so still keep compiled code?

The namespace of the subVIs themselves changes, so I'm afraid that separation of the compiled code alone is not enough. The linking information in the diagram heap has to be modified to record the new name which now includes the library namespace. As long as it is only a recompilation of the subVI, separation of compiled code in the caller indeed should not require a recompilation of the caller, but name changes of subVIs still do.

In fact the automatic relinking from non-namespaced VIs to library namespaced VIs is a feature of the development environment but there is no similar automatic reversal of this change.

Edited Wednesday at 10:09 AM by Rolf Kalbermatter

[ShaunR]

58 minutes ago, Rolf Kalbermatter said:

The namespace of the subVIs themselves changes, so I'm afraid that separation of the compiled code alone is not enough. The linking information in the diagram heap has to be modified to record the new name which now includes the library namespace. As long as it is only a recompilation of the subVI, separation of compiled code in the caller indeed should not require a recompilation of the caller, but name changes of subVIs still do.

In fact the automatic relinking from non-namespaced VIs to library namespaced VIs is a feature of the development environment but there is no similar automatic reversal of this change.

If that's the case then is this just a one-time, project-wide, recompilation? Once relinked with the new namespaces then there shouldn't be any more relinking and recompiling required (except for those that have changed or have compiled code as part of the VI).

[Rolf Kalbermatter]

2 hours ago, ShaunR said:

If that's the case then is this just a one-time, project-wide, recompilation? Once relinked with the new namespaces then there shouldn't be any more relinking and recompiling required (except for those that have changed or have compiled code as part of the VI).

That's my understanding yes. I have so far not upgraded to the library versions of the OpenG libraries, so do not have any long term experience with this. When I upgraded by accident one of the libraries I did see that it seemed to automatically relink callers, but that was not what I was prepared to deal with at that point as I was only making a minor edit to the project, so reverted to the previous OpenG version rather than committing the modified VIs to source code control.

[iannicholson]

So here's the story behind my previous statement.

Last night I opened LabVIEW 2021 (21.0.1f2) to investigate a problem someone was having with software we provide for machines we sell. For reasons I can't currently explain, I was presented with a dialog listing several VIs (19 I think) and the following message for each one:

OpenG Libraries support for LabVIEW 2021 is missing and is referenced by the following VIs

This is very strange because I know I updated the OpenG Libraries months ago (possibly nearly a year ago) and have never had this come up before. Once I opened my main VI, I found that it was broken, and drilling-down into the sub showed that multiple VIs were broken (including the GCraftsman JSON Object Serialization library I briefly used but never got back to.

I spent about 4 hours researching why this would happen. I found several references to the updates to the OpenG libraries, and some recommending downgrading the libraries to the previous versions (version 4.x and 5.x). I tried this, but ended up with different errors. Eventually I realized I hadn't yet restarted LabVIEW after the downgrade, so I chalk the new errors up to that. But after restarting, then downgrading and re-upgrading to version 6.x of OpenG, suddenly the problem is now resolved.

My frustration in the earlier comment was that this update was going to prevent me from using GCraftsman's library specifically, due to the fact that I can't find any recent info from the developer anymore. This led me to worry for other users of libraries that can't be fixed after such a change.

It appears this was a false alarm since my code now runs fine; I guess reinstalling the OpenG libraries did the trick, but I have no idea why this was needed. The recompile triggered after the update seems to be working as intended even if it didn't originally work at all for me? Anyway, sorry for the disruption.

[Neil Pate]

I actually had a similar experience when first moving everything to the new OpenG structure. It broke heaps of stuff (even inside its own OpenG stuff), so I rolled back the change.

Some time later I tried again, and think I did have to deal with a bit of pain initially with relinking or maybe some missing stuff, but since then things have been stable.