LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
manu.NET

Ability to create a Packed Library, without having to create a LVLIB ....

Status: Declined
This idea was rejected during the design phase of PPLs. More info in AristosQueue's reply here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Ability-to-create-a-Packed-Library-without-having-to-c...

Hello,

 

For the moment, when you want to create a Packed Library you have first to create a LVLIB. Smiley Sad

The PackedLibrary build specification is based on a LVLIB ...

 

PackedLibrary.png

 

It would be nice to be abble to create a Packed Library the same way as a Shared Library (DLL). Smiley Happy

 

  • Be abble to choose every VI to publish : The exported VIs are automaticcaly 'public'
  • All other depending VIs or 'always included' VIs would be private ! 

Shared Library.png

 

Thanks a lot.

 

Manu.

Manu.net
5 Comments
AristosQueue (NI)
NI Employee (retired)

This idea was rejected during the design phase of packed project libraries. LabVIEW is moving away from ad hoc creation of code artifacts based on arbitrary build specs and toward source code that specifies how code is going to be used/deployed. In the long term, that trend will make it far simpler to debug code because you can tell your caller code to refer either to the source version or the compiled version, and swap them out cleanly as needed. It facilitates version control for the produced code artifacts.

 

R&D hopes/expects over the next few years to transition to a system where you declare "this set of VIs is a library", and then you have different deployed forms of that library -- as source files, as object files, as a single packed file, as DLL -- each of which is equally viable as a dependency for caller source code. Adding the ability to make arbitrary packed project libraries at build time would be a major step backwards on that goal.

Darren
Proven Zealot
Status changed to: Declined
This idea was rejected during the design phase of PPLs. More info in AristosQueue's reply here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Ability-to-create-a-Packed-Library-without-having-to-c...
manu.NET
Active Participant

Hello,

 

I think you have close this idea quiet rapidly.

 

The principle of ideas is to ask to the LabVIEW users what they would like to have.

 

Here you answer by saying ... it's not 'developpement staff' way of thinking.

Let, please, a little bit more time to the LabVIEW users, before 'declining' an idea.

 

Certainly the way i poste the idea is not good, because i don't have a complete visibility on LabVIEW architecture ...

 

But, by discussing around the problem could reach to a new feature.

 

Thanks a lot.

 

Manu.

Manu.net
AristosQueue (NI)
NI Employee (retired)

> The principle of ideas is to ask to the LabVIEW users what they would like to have.

 

We asked. You told us. And we said no. We did not say no just because. We said no because we have other customer requests that we have heard/observed that conflict with this one, and those others are higher priority. We firmly believe this request is a bad idea that would undermine more projects than it would help.

brentjustice
Member

I recently encountered a niche situation where I desired the ability to build an auto-populating folder of VIs into a PPL.

 

As noted here, packed library build specifications require a top-level library declaration.
However, I found that a workaround is possible.

I was able to create an empty lvlib as the top level library.
Then I added the auto-populating folder of VIs as "always-include"

These VIs are not visible if you open the LVLIBP file in the LabVIEW IDE.
But the VIs are still compiled into the LVLIBP.
And I find that I'm still able to access/launch them by opening VI ref by path, and then running VI be ref.

This met my needs.