Jump to content

Search the Community

Showing results for tags 'add ons'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Software & Hardware Discussions
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • OpenG
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help


  • *Uncertified*
  • LabVIEW Tools Network Certified
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
    • Custom Probes
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website

Company Website

Twitter Name

LinkedIn Profile

Facebook Page



Found 1 result

  1. Recently I was tangentially involved in a software management mess where the fact that a 3rd party LabVIEW add on was not in our source control (SVN) made it very difficult to build a new binary of a previous revision. This particular add on has many revisions. It is a work in progress as we and the 3rd party do R&D on the application. In addition they are primarily PhD's in something other the Software Engineering. The code shows this and noteably the pinouts to the applications VIs change from revision to revision. I think the OO jargon for this is Highly Coupled, meaning certain revision of our code work only with certain revisions of thier code. We have a situation where instead of any developer being able to do a build at any time, only one or two machine can succesfully build this project. I was reading other threads on this forum, specifically http://lavag.org/topic/13492-reuse-packages-and-scc/ and it looks like VIPM might be an answer. But I have specific questions about how it would work. Apparently there is a VIPC file that would be committed to SVN or any SCC. When exporting, a developer would use this file in some way to verify that the right version of the packages are installed. Is this correct? What is the "some way"? Will this process downgrade the 3rd party add on as needed? Presumably also the VIPM would in some way make sure there were not two version of the packages in the VIPC, or do something else to prevent cross-linking? So the way I imagine the use would be: Checkout the code from a previous revision. Update the 3rd party add ons to the correct version based on the VIPC file. Build the binary and installer. Delete working folder. Or if a we needed a branch of a previous revision say 5.1 from 5. Checkout version 5. Update the 3rd party add ons to the correct version based on the VIPC file. Make the required 5.1 revisions. Check the VIPC for new dependencies. Build/Test/Validate etc... Commit changes including VIPC. Is that right and does VIPM handle the package updates and dependency checks? Thanks!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.