Allow packaging of VIMs alongside/with PPLs

[cbutcher]

At present, using a malleable VI in almost any form alongside PPLs seems to be largely impossible.

Of course, a malleable VI is a template of sorts, and a PPL is the compiled form of some library. I can see this makes including the malleable VI impossible (at least without a predefined list of allowed types, at which point you could use the VIM as a private VI and define a set of public or private VIs, then call those from a public polymorphic VI).

However, it would be nice if we could define a VIM (either in, or alongside) a library in a project, and have it be placed in e.g. the Support destination (or specified destination via the Build Specification settings).

A quick attempt to do this resulted in the following:

• Create a library with two VIs, one outputting a number and the other a string.
• Create a VIM that has an input used only for type matching, and a Type Spec Structure for Assert Structural Match on string, int32, output the appropriate matching result type from one of the two (public, in this simple test) library VIs
• The first case of the TSS is the string one (seems relevant to outcome).
• Build the library into a lvlibp, with the VIM set to Always Included, and the destination set to Support.
• The output files are A.lvlibp, Output String.vi, Get Value.vim.
• A.lvlibp only contains Output Num.vi, not the string anymore.
• The VIM is not loadable via project (although it opens broken alone), because it calls A.lvlibp:Get String.vi, which doesn't exist.
• Get String.vi is unloadable, seemingly because it requires (perhaps it expects to be) A.lvlibp:Get String.vi...

Could this please be improved? 🙂

Ideally the VIM that is placed in the accompanying destination should link to the VIs in A.lvlibp, and none of the VIs should be missing in that PPL.

[AristosQueue (NI)]

TL;DR: This idea appears to have nothing particular to malleable VIs. It is about any sort of source distribution that depends upon a built PPL. And I'm not sure that anything is actually broken in LabVIEW keeping you from doing this. My temptation is to Decline this idea, but I will wait for your reply to the information below.

Details:

> At present, using a malleable VI in almost any form alongside PPLs

> seems to be largely impossible.

If I read your steps correctly, nothing inside your PPL calls the VIM. Do I have that right? If so, this is no different than distributing any other source that depends upon the PPL... nothing special about the VIM.

1. Write project that has .lvlib and code that calls the .lvlib.
2. Build your PPL.
3. Replace the lvlib with the lvlibp in the project, which updates all callers (including the VIM).
4. Build a source distro for the updated source.

Now, personally, I'd encourage you to have two separate projects, one for the lvlib that builds the PPL and a second that has all the code that depends upon the PPL, but the above steps are how you can have them together. If you have the second project separate, replacing the .lvlib with .lvlibp doesn't destroy your Build Specification, and you can still do debug in the second project by replacing .lvlibp with .lvlib temporarily.

[cbutcher]

Yes - after posting I realised that if I put the malleable VIs in a separate project, and build them only after the PPL is built, then things will work properly.

The problem described in my post with lvlib VIs being dragged somehow out of the lvlibp during the build process is presumably more of a bug than a feature request, so it's not appropriate for the Idea Exchange.

As a result of those, I guess this idea is more "can we have a way to store accompanying source distributions in/with a PPL"?

I assume placing non-compiled code inside a packaging vehicle explicitly designed as a compiled-code only file is a non-starter.

I don't know if the process can be improved for my use case, but having two separate projects is not particularly onerous, and if I at least mentally package them as one item I can avoid versioning the VIM separately, probably...

Is it possible to have a malleable VI access non-public members of a library that is compiled into a PPL? I haven't tried but perhaps community scope can be used here - the VIM doesn't change namespace during its "build" (although, there might not really be one, so much as copy-pasting into location) and so I guess I could have the lvlib list the VIM as a friend, and then the VIM depend on the lvlibp (I just checked that adding a friend doesn't bring it into memory, so hopefully this doesn't create a circular dependency).

Unless somewhere in my rambling above you see something that looks like it's worth discussing, please feel free to decline this idea.

[crossrulz]

What I recently ran into was I wanted a privately scoped VIM built into a PPL.  I wanted it in order to avoid code duplication (a number of instances in a polymorphic VI call the VIM, accessing private data of a class).  But, alas, the compiler complained about a VIM going into a PPL.

[cbutcher]

Really? I just tried this in 2019 and it seemed to be OK (at least with the Preview, I didn't actually build...).

I know that building PPLs with public VIMs became broken with the release of 2019 (previously they were silently removed).

[AristosQueue (NI)]

crossrulz:  I had to do that recently (within last two weeks). Worked for me. Are you sure the VIM was private? If it really was public, and if you can share the code, then please submit that as a bug to NI through the usual channels.

[Darren]

Declined per cbutcher's request

[crossrulz]

So I finally got back to the library that caused my error mentioned earlier in this thread.  It appears to be caused by my VIM being inside of a virtual folder in my library.  I started a thread here to discuss it.  There is even an example project showing the bug.