LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I build a source distribution with dependencies in a llb or specified target folder?

I am trying to build a source distribution.  I have a lot of vi's in a project.  A subset of these vi's makes up the developer level interface as an API for a product.  But there are of course numerous lower-level vi's and dependencies that also must be distributed.  So I want to have my top-level vi's all being disributed to a set of folders (that part's easy) and I want all the dependencies to go some a big llb or at least some other folder.
 
But when I try to specify the destination for "dependencies" it is greyed out in the application builder and the thing is stuck to "same as caller".  That means when I run the distribution it puts hundreds of dependency vi's in every desitination folder so the whole thing is useless.  It would probably be easier to build the disribution by hand using "save as" than weed out hundreds of low level vi's from top-level vi's and re-structure the whole distribution by hand with all the relative paths corrected.
 
 
My dependencies are spread out though a whole network of folders, so its not like I can easily consolidate them all to one place.  That's what the source distribution is supposed to do for me.  This is labview 8.2 BTW.  Any way of making dependencies go someplace else?
-Devin
I got 99 problems but 8.6 ain't one.
0 Kudos
Message 1 of 13
(6,356 Views)

Howdy,

Can you refresh the Dependencies and/or have it so we can view the files and folders?

Charlie M. CLD
0 Kudos
Message 2 of 13
(6,330 Views)

There are hundreds of them and they are greyed out like always.  But here is an image with dependencies refreshed.

-Devin
I got 99 problems but 8.6 ain't one.
0 Kudos
Message 3 of 13
(6,318 Views)

Howdy Again,

In the “My Source Distribution Properties” window you can set the “Distribution Settings” to different packaging options. It sounds like you have it set to “Single Distribution-Preserve Hierarchy.”I would use “Single Distribution” to start. This did the trick when I was trying to recreate your problem.  

Charlie M. CLD
0 Kudos
Message 4 of 13
(6,301 Views)
No.  As I said before, this is labview 8.2.  Are you sure you are using 8.2 to recreate this problem?
 
This is set to "single distribution - custom".  I am not preserving hierarchies.  See below:
 
 
Any of the folders in my project can be added to any custom destination.  See below:
 
 
But as soon as I click on "dependencies" the option to select the destination gets grayed out and is stuck at the defaul of "Same as caller".  This puts hundreds of low level vi's in the same directoriy as the caller.  So if I do a source distribution of one vi with 100 dependencies, I get a folder with 101 vi's in it.  I can't set the dependencies to a different folder.  Use labview 8.20 to recreate the problem.
 
 
 
-Devin
I got 99 problems but 8.6 ain't one.
0 Kudos
Message 5 of 13
(6,296 Views)

FYI, correspondence with NI apps engineer: Confirmation that labview 8.0 and 8.2 cannot do useful source distributions.  (Further proof that labview 8.0 and 8.2 are a waste of time and should never have existed.)

 

Hi Devin,

Have you had any more luck getting your source distribution to build

properly and place your dependencies in the proper paths since we last

spoke on the phone? I'd like to confirm some source distribution settings

with you to make sure we're on the same page. As I recall, it was your

dependency files that were all going to the wrong place, correct?

I have attached an image of my settings on a test build which should

hopefully help you out, even though they look like things we've already

tried. As long as the support directory and data directories are different

in the "Destinations" category on the left, setting all dependencies'

destination to Support Directory (rather than "same as caller") should

hopefully fix that problem. Once you have those settings in place, try

pressing OK and then coming back into the source distribution properties

and checking to see if they're still set the way you left them. You can

then add a password to all included dependencies to disable an end-user

from accessing those files.

Please let me know if this proposed solution works out for you or not.

Regards,

Applications Engineer

National Instruments

-----------------------------------------------------------------------------------------------------------------

When I click on dependencies the option to change to destination is grayed out. Please see the attached image.

I am using labview 8.2, and upgrading to 8.5 is not a viable option. I have invested way too much time into labview 8.2 to change versions right now.

When you use labview heavily in an industry, and you have built up a big library of code, it takes about one man-month to upgrade from one labview version to another. So upgrading again is not an option. I already spent three months this year just getting to 8.2. 7.1 to 8.2 was a particularly ridiculously buggy upgrade that generated dozens of instances of broken code and/or nonfunctional code that once worked. I also had to create dozens of new project files and executable builds because none of the build scripts from 7.1 imported properly. I can't go through that again, and my bosses won't let me waste that much time again if I wanted to. So I am looking for a patch or some way to use the $4000 labview 8.2 license I am currently developing under to build a source distribution, the way you could always do in labview 5.1, 6.0, 6.1, 7.0, and 7.1, without having to spend another month migrating thousands of vi's to yet another labview version. I just want to find a reasonably stable labview version and never upgrade ever again to be honest.

Is there any way to build a useful source distribution in labview 8.2?

 

------------------------------------------------------------------------------------------------------------------------------------

Hi Devin,

I apologize for sending you a LabVIEW 8.5 solution when you were using LabVIEW 8.2.

After researching the issue thoroughly, unfortunately it appears as though you cannot change in 8.2 where the dependencies in a project are placed - they can only be placed within the same directory as their callers. I also conferred with some other engineers and we could not come up with a viable workaround for you in LabVIEW 8.2.

Our R&D team made significant changes to the way the Application Builder toolkit behaved between LabVIEW 7.1 and 8.0. While source distributions worked in the way you are describing in previous versions, this functionality was not maintained for 8.0 and 8.2. Due to customer demand, however, it was re-implemented in LabVIEW 8.5. I realize, however, that you are unable and unwilling to upgrade at this time to version 8.5.

I wish I had a better answer for you, and I am sorry that your upgrade experience has been frustrating. I'm going to go ahead and set this service request to close out within 5 more business days, but if there's anything else I can help you with, please let me know.

Regards

Applications Engineer

National Instruments

-Devin
I got 99 problems but 8.6 ain't one.
0 Kudos
Message 6 of 13
(6,277 Views)

Hello Devin,

 

I understand that you’d like us to revisit this issue.  I think I understand your use-case and your need to have the dependencies go to a lower-level folder than your API (top-level) VIs in your source distribution.  You and the AE you spoke with are correct; LabVIEW 7.1 has a more advanced “save with options” dialog that allows you to create what now is known as a source distribution.  This was replaced with source distributions, but 8.2 is not capable of preserving the hierarchy when creating a source distribution in some cases (this has been recognized as a bug and fixed in 8.5).  One thing that you may not know is that a lot of the functionality of the 7.1 save with options has been preserved in 8.2 which may be of use.  If you have an already saved VI with a VI hierarchy, go to “save as” and you’ll have an extra option:


 

This does not include vi.lib , instr.lib, or user.lib VIs and won’t include dynamically called VIs which could cause problems depending on the specifics of your application.

 

The code-changes between 7.1, 8.2, and 8.5 in app builder are non-trivial.  They involve both VI changes and c-code changes internally.  So, unfortunately, using one version of app builder in another version to work-around this 8.2 known issue is all but guaranteed to fail.  With a few more details about your application, we might be able to make another recommendation.

 

Have a great weekend-



Message Edited by Travis M. on 02-29-2008 04:13 PM
Travis M
LabVIEW R&D
National Instruments
0 Kudos
Message 7 of 13
(6,026 Views)

Thanks for at least investigating the issue further.  I've spent hours and hours wrestling with building a source distribution, so of course I am very aware of the different options to create source distributions in 8.2.  The hierarchy option is sometimes helpful, but it doesn't really help me in this case because it creates dozens of hierarchy directories for all the dependency vi's scattered around.  I need a way to get all those dependency vi's to a consolidated place with the relative paths in their callers corrected to the new dependency location.  In 7.1 you could at least prompt for every dependency vi, so you could save them all to a single support folder and the relative paths would be right.  If I use hierarchy I have to then manualy move all the dependencies from their hierarchy paths to a consolidated support location and then load every API function and get all the paths corrected.

I can't distribute my API in 8.5 because our customers don't all use 8.5.  So for now I develop in 8.2.  I use my own code to copy all loaded vi's hierarchy to a new base location, basically the same way the preserve hierarchy selection works in the source distribution except without as much overhead lag.  Then when I have the duplicate hierarchy I isolate it to a hard drive of a machine with 8.5.  I do the source distribution in 8.5, then save for previous back to 8.2.  Then I copy the 8.2 distribution back to my network where I mass compile it again in 8.2 and re-test it to make sure everything still works.

I was hoping there would be a way to run the source distribution from 8.5 in 8.2 so I wouldn't have to bother with all that copying and testing.  I was thinking if the code was portable enough maybe there was a way to drop the 8.5 version over the 8.2 version.  But if there is underlying C that excludes this possibility I'll take your word for it.  I thought it was worth a shot to ask.



Message Edited by billings11 on 03-03-2008 09:34 AM
-Devin
I got 99 problems but 8.6 ain't one.
0 Kudos
Message 8 of 13
(6,007 Views)
Hello Devin,

It never hurts to ask, and if this feature was implemented strictly in G, it would theoretically be possible, but as mentioned it isn't…  However, I think we may have a suggestion that could get you pretty close to what you have in 8.5.  When your project is complete and ready to be built into a source distribution, right click the "dependencies" and hit "refresh" to make sure you have a complete list of the dependencies.   Then, create a new virtual folder in your project, name it 'dependencies' or anything you'd like.  Go to your source distribution window, and in the "Distribution Settings" page, select "Custom" for packaging Option and configure the additional directories you'd like to use.  In your Source File Settings page, you can choose to send all the dependency VIs to the directories you configured in the Dist. Settings page, just use the "Set destinations for all contained items" checkbox for the entire folder, or uncheck to configure individual VIs.  I think this may get you to the 8.5 behavior and prevent the save for previous and compiling.  Be sure to refresh you dependencies, and re-copy the files from dependencies to the dependencies virtual folder before you build your distribution if you make any changes to your project!!  One way to check to make sure you have all you need is to "refresh" your dependencies in the project.  If you have all the dependencies included in your project file, you shouldn't see any in the dependencies  drop-down.  I'm eager to hear if this is satisfactory, let us know.

Have a great afternoon-

Travis M
LabVIEW R&D
National Instruments
0 Kudos
Message 9 of 13
(5,974 Views)
Travis,
 
That is a pretty good solution.  Its far better than migrating the whole thing to 8.5 temporarily!  It is only a little more work to maintain than the 8.5 source distribution, just to check each time I build that I have all the dependencies in the virtual folder and that I've removed anything that is no longer used.  But I think this is a perfectly adequate workaround.
 
Thanks!  That just saved a few dozen hours I'm sure!
 
-Devin
-Devin
I got 99 problems but 8.6 ain't one.
0 Kudos
Message 10 of 13
(5,967 Views)