Separate Compiled Code for vi.lib

[code-lux]

To track changes I make in the vi.lib in SCC I set Separate Compiled Code for the affected VIs.

Does Separate Compiled Code for VIs from vi.lib have performance issues for LabVIEW?

Why does NI deliver VIs with included Compiled Code in the vi.lib?

Does anybody have a good proceedure to merge own changes in vi.lib with new LabVIEW patches?

[GerdW]

Hi lux,

---

@code-lux wrote:

Does anybody have a good proceedure to merge own changes in vi.lib with new LabVIEW patches?

---

Generic advice: don't change any code within vi.lib!

Create your own user.lib where you can place copies of code from vi.lib...

[Kyle97330]

---

@code-lux wrote:

Why does NI deliver VIs with included Compiled Code in the vi.lib?

---

Because it's not expected that users should change vi.lib code!

GerdW says "Create your own user.lib where you can place copies of code from vi.lib", which I somewhat agree with except for some nitpicks.

Nitpick 1:

Don't just copy them, copy and rename them.  If you don't rename them, you're almost certain to get conflict popups at some point.

Nitpick 2:

If you honestly feel there's something wrong with vi.lib code, then you might want to post some of what you're doing to it.  Most vi.lib code has been with LabVIEW for decades, and while in some cases it remains unchanged for compatibility, in most cases it remains unchanged because it's working well after having been used by tens of thousands of people.  If you think there's something that "needs" to be fixed (as opposed to adding new features or custom company-specific interactions), there's a reasonable chance you're wrong about it.

[code-lux]

Hi Kyle and Gerd

Thanks for your answers.

Several of the big addons you can get on VIPM are changing the vi.lib and tools like Quickdrop are there and we are officially encouranged to add our own scripting there. And my code is just working fine.

But I find the maintainance of it in case of LabVIEW updates awkward and I hope to get some tips from others how they handle it.

I.e.: did anybody try to Separate Compiled Code for all VIs in vi.lib?

As NI starts to make code open source like Icon Editor and Actor Framwork (both part of vi.lib) I´m optimistic that it will become easier to track changes in the vi.lib

[code-lux]

Hello LabVIEW scripters and NI Insiders

So far nobody answered my questions...

I´m sure there is knowledge around about Separate Compiled Code for VIs from vi.lib - would be great if somebody shares it 🙂

[rolfk]

First, your development should never happen in vi.lib, user.lib, and maybe even instr.lib. These locations are library installation locations for fully developed libraries that you want to distribute to other users. Consider it similar to your C:|Program Files\<something> path. You should not develop an application in that location, no matter which development environment/programming language you use. If you need SCC in any of these places you are pretty much making something very wrong.

Development and testing should happen in a project specific development location. And yes this of course means that your code should NOT work with absolute paths in your VI diagrams when referring to anything in your library. It should be able to dynamically adapt to a different installation location.

Once your library works, has been gone through all necessary reviews and unit tests and what else, you build an installer package (VIPM, OGPM or your own NSIS or whatever installer based system) and one final test needs to be done that it installs properly and that the functions work as intended.

[code-lux]

Hi Rolf

Thanks for your answer - I appreciate that you do not just tell me not to work in the vi.lib but also present a way of how to do it differently.

I'm not developing applications in vi.lib and I´m not changing code that goes into applications. I'm changing the scripting that is also present there. Things like Quick Drop, AF Message Maker, Right Click Menus. So, it's always LabVIEW itself that calls those VIs, I don't see how that could work for test or use when my changes are at a different location?

[code-lux]

Meanwhile I found some useful description to handle the SCC proceedure:

SVN Book: Vendor Branches

These 2 questions are still open:

Does Separate Compiled Code for VIs from vi.lib have performance issues for LabVIEW?

Why does NI deliver VIs with included Compiled Code in the vi.lib?

[rolfk]

One thing I can think of is that vi.lib is HUUUGE. Adding all those VIs to the object code cache would really blow the embedded database up. And every time you clear the compiled cache because of some weird problems trying to build an executable or package, it would have to rebuild that again too.

As you are not supposed to change vi.lib or add code under development in any of the lib directories under any normal situation (99% of users) this is most likely the more sensible choice than separating the code from the VI.

[crossrulz]

---

@rolfk wrote:

One thing I can think of is that vi.lib is HUUUGE. Adding all those VIs to the object code cache would really blow the embedded database up. And every time you clear the compiled cache because of some weird problems trying to build an executable or package, it would have to rebuild that again too.

---

I'm fairly certain vi.lib has its own compile cache, separate from the user compile cache. A user cannot just clear the vi.lib compile cache.

I do know more and more parts of vi.lib is being saved with separate compile. This is required for the LVAddons feature, which NI is moving more and more into.