Make the LabVIEW "resource" folder a symbolic path

[Jim_Kring]

I've posted an idea, here (<< please kudo it), on the LabVIEW idea exchange that would make it possible to build LabVIEW Add-ons that call subVIs located beneath the "<LabVIEW>\resource" folder.  Currently, this is not (easily) possible, because the resource folder is not a Symbolic Path.  The end result is that doing a source distribution (for example using VIPM to build a package) causes relative paths to get all wonky and nothing works right.

[chris.b]

For the uninitiated, I think your explaination of the problem on the IE is very good:

LabVIEW add-ons that link to VIs beneath the resource folder [e.g. \resource\Framework\Providers\API] cannot be moved to a new location (for example as part of a source distribution build step), otherwise they will not be able to find these resource subVIs (since they link via a relative path between the caller and subVI, rather than a relative path between the resource folder and the subVI).

I most definitely agree that this is a problem and I want to address it. First, I'd like to fully understand why developing under the LabVIEW directory is unacceptable. Is this primarily because of source code control constraints? Is it still impossible to build an SD even if you developed here? I may sound skeptical or negative, but I am actually just trying to ensure I understand the whole problem and that we are all on the same page.

You mentioned in your email that the "quick and easy fix is to make it [\resource] a Symbolic Path." I would like that to be true. But I do have my doubts, as anything that affects paths affects the Linker. Changes to the Linker are scary and could have ramifications on many areas (labview.exe, modules, toolkits, VI load times, LV start up speed, etc). Let me do some research and see if this would be a viable option.

[Jim_Kring]

> First, I'd like to fully understand why developing under the LabVIEW directory is unacceptable. Is this primarily because of source code control constraints?

IMO, it slows down the software engineering process with lots of extra manual steps and makes things really unnecessarily difficult.  In *any* software product, the "source code" and the built "software product" should be two different things -- very rarely is the preferred form for development the same as the preferred form for distribution and use.  LabVIEW blurs this line, but it still exists.  By saying that you need to develop your sources in place under LabVIEW, you're saying that you can't (easily) have a build process.  But, there are a ton of things a vendor may wish to do to transform the sources into the built product (password protection, etc.).

> Is it still impossible to build an SD even if you developed here?

You can build a source distribution (the build process does not fail), but you'll need to ensure that the build output location is the same location were you intend for the built add-on to be installed on the end user's LabVIEW installation.  And, if the built add-on is moved to a different location, it will no longer work until relinked to the resource VIs.

> I may sound skeptical or negative, but I am actually just trying to ensure I understand the whole problem and that we are all on the same page.

No problem

> You mentioned in your email that the "quick and easy fix is to make it [\resource] a Symbolic Path." I would like that to be true. But I do have my doubts, as anything that affects paths affects the Linker. Changes to the Linker are scary and could have ramifications on many areas (labview.exe, modules, toolkits, VI load times, LV start up speed, etc). Let me do some research and see if this would be a viable option.

I agree that there could possibly be side-effects, but I'm about 99% sure that everything will be OK (re load time: does it take longer to resolve a symbolic path, than a relative path?).  Making "resource" a symbolic path would affect the way links are saved, moving forward, but the old (relative) links will still work.  So, this just adds a new/better way for VIs to link to stuff under the "resource" folder.

OK, let us know how the research pans out. Thanks!

[GregR]

Where are the VIs you create going to be installed? Will they be under resource or will they be somewhere else and just reference things under resource?

My concern is the linkages between your VIs. If the VIs are saved under a symbolic path, then they will refer to each other with symbolic paths. If the VIs are saved elsewhere, then they will use relative paths. In the past we've had problems with copying files from other locations to under a symbolic path because of this difference. It would cause VIs to be get docmods and path warnings. I'm not sure if these are all better now. I know going the other way is a problem. If you copy VIs out from under a symbolic path, their references will still be loaded from the symbolic path.

[Jim_Kring]

> Where are the VIs you create going to be installed? Will they be under resource or will they be somewhere else and just reference things under resource?

Both cases happen.  Yesterday, someone was trying to build a package that called a VI from the icon editor, which is installed under the resource folder -- in this case, our advice was to make a copy of the subVI (if possible) and pull it into the project.  In many cases, we're trying to package VIs that call project provider APIs.

> My concern is the linkages between your VIs. If the VIs are saved under a symbolic path, then they will refer to each other with symbolic paths. If the VIs are saved elsewhere, then they will use relative paths. In the past we've had problems with copying files from other locations to under a symbolic path because of this difference. It would cause VIs to be get docmods and path warnings. I'm not sure if these are all better now. I know going the other way is a problem. If you copy VIs out from under a symbolic path, their references will still be loaded from the symbolic path.

The case where VIs are developed outside a symbolic path, and then are moved under a symbolic path, doesn't concern me too much, since we already do this for all our reuse libraries that are developed outside of user.lib/vi.lib and then copied there during installation.  The case where VIs are developed under the resource folder, such as needing to develop a project provider while its in its installed location, does concern me a little since the links become relative to the pathroot.  IMO, a good solution to this problem would be to provide a way for add-on developers to specify a folder/location for providers under development to be loaded from -- this way, the provider sources are never under LabVIEW when they are being developed.  Another solution, as you mentioned, it to move the provider APIs into vi.lib (or some other new symbolic path like editor.lib).

[Mattias_Ericsson]

Hi Chris,

I've done some heavy developement using the project provider API in the <resource> folder. I've come to the conclusion that I am almost forced to develop directly into the <resource> library, which I do for two reasons:

1) Quick response to changes (just restart LabVIEW)

2) Fear of the getting crazy links as Jim described, especially as we place some VIs in the <project> and <help> folders as well, linking to the main package in <resource>.

Then I just use a bat-script to zip these files from LabVIEW to place in our source control system. Then all links are fine.

We did try to develop "outside" LabVIEW, lookin good at first, compiled just fine and everything, but then we noticed that the paths to the files referencing to the <resource> was not relative anymore, but full absolute (the working space wasn't located at c:). Didn't notice anything when making a test installation in the same version as the code was built into. But when testing to install to a newer version of LabVIEW like LV2009->LV2010 on the same maching, The <project> and <help> files that was copied into LV2010, actually pointing to an absolute path into LV2009! When just saving VIs in 2010, it actually recompiled the resource VIs and some vi.lib VIs in LV2009 to LV2010, actually destroying the LV2009 installation and caused us to reinstall LV2009. That wasn't too popular... We are now deveping directly into <resource> in LabVIEW and double checking linkage each time for a new release.

Just some experience using the <resource> folder and the problems and dangerous situation that might occur if you are not careful enough.

I really agree with Jim, please make <resouce> a symbolic path, this would make life much easier for addon developers, both for building VIPM packages, but also for the source code management. Developing directly in <resource> isn't an ideal situation, but "link safe".

Mattias

[JeffBoettcher]

Hey Mattias, Jim, et al,

I am looking into this a bit, and was just trying to get my head around specifically what problem we're trying to solve by making <resource> a symbolic path.  I understand you would like to build addons that support multiple versions of LabVIEW, for distribution with VIPM.  Is the core issue that you would like to be able to edit VIs that you intend to install with LabVIEW while they are not in their installed location?  Generally it seems like if you wanted to support back to LabVIEW 2009, and you edited your VIs using LabVIEW 2009 while they're located at the path to which they would install into LabVIEW 2009, you wouldn't have any problems.  Do you agree with that statement?  If so, which part of it is concerning to you?  Or am I missing the point altogether?

Thanks!

Jeff

[Jim_Kring]

Hey Jeff,

The fundamental problem (observed by users) is that we can't "build" packages of project providers with VIPM (or the LV Source Distribution Build Spec, for that matter), since <resource> is not a symbolic path -- the preferred form for developing is very rarely the preferred form for distribution, so we always need to "build" it.  This means that any time you move stuff around, the links (to various framework API VIs) all become relative to the new/moved location, rather than the location relative to <resource>.  So, if the built component is moved around, then stuff breaks.  And, developing things in place (editing VIs when they are in their installed location) is only a development practice that really works well for NI (IMO).

Sorry if my response is terse.  My Friday is dissapearing quicky, and I've got to run

Cheers,

-Jim

[Mattias_Ericsson]

Hi,

Very well written. Exactly my point of view as well.

/Mattias

[AristosQueue (NI)]

A) I want to know why this isn't fixable with a minor tweak to VI Package Manager.

• Option 1: Allow the source files for a package to be in the LabVIEW directory.
• Option 2: Continue to require the source files exist outside LabVIEW in directory XYZ. They are going to be installed into directory <labview>\resource. When VI Package Manager loads the VIs to build them, why not just set the VI Path to be the path they will eventually be saved at, so that when you serialize the files, they save with the correct relative paths?
• Option 3: Continue to require the source files exist outside LabVIEW in directory XYZ. When VI Package Manager loads the VIs, it detects any subVIs that are inside LabVIEW and not at pseudo paths and makes local copies of those VIs in the correct relative positions with the source files, but leaves those files out of the package.

B) I object to making <labview>\resource be a pseudopath. We have a problem with vi.lib that everything in that directory is linkable by user code. We have not taken steps to secure the not-in-the-palette VIs to prevent them from being linked by users, which continues to leave us open to a repeat of the "Config VI Refactoring Debacle". I discovered that I can put useful VIs into the resource directory and thus make them available to users but in a form that LV is not bound to support them or maintain them in the next version of LabVIEW. Everything in resource is very version specific. If we scrap the Icon Editor, will that cool little graphics utility subVI that you've been calling still be around? Possibly not. A pseudopath link encourages people to use the stuff in vi.lib --- that's why we have the pseudopath link. The lack of one discourages use of the items in the resource directory unless (A) your code is being installed into the resource directory or (B) you make a copy of whatever the subVI is for your own uses.  The partners who are developing plug-ins for the project are knowledgable, cautious users that we have good communications with if we change something that breaks them. That's not true of the casual user. I don't want us to open a door that most users can walk through just for the sake of the very few who are developing providers.