library source control

[rickales1]

As a followup, I too am looking for a  "best practices" guide on how to set up a program consisting of multiple project that ideally would share reusable VI packed libraries.  Individual project are not an issue.  I believe what can quickly get out of hand without a good place would be the following for example:  Library revsion control and how to push updated program librarys to individual project applicaiotns when required.  For instance, creating a new project requires an additional parameter to a control that is ured in multiple projects? Once the control is updated, do all the projects (runningi in runtime as exes) where used need to be relinked?  Maybe this not a real concern for the existing exe, but could complicate future revision of the the exe project?   

I found a link to "Managing Large Applications with the LabVIEW Project." but it seems to be dead?  Can someone point me in the right dirieciton. 

[Gregory]

---

@rickales1 wrote:

As a followup

---

As a follow up to what? This is the first post of the thread.

It looks like you can put .lvproj into a different project, but I don't know how useful that is. You probably want the LabVIEW Library (.lvlib) filetype. This will allow you to have multiple VIs with the same short name, but in different libraries, in the same project. Also, you can change the library icon overlay to easily have a different colored icon for different libraries.

[Sam_Sharp]

Are you definitely talking about Packed Project Libraries (.lvlibp) files? Or just re-use libraries in general? .lvlibp's are more commonly used for distributing plugins in a built executable but it's not entirely clear if you're talking about sharing your source files between projects or sharing plugins between executables.

[rickales1]

Yes I understand using packed libraries to help manage broken links with distribution.  I am looking for an AppNote or White Paper that in general discusses best practice for organizing labview projects from the enterprise prespective with the goal of revision control, multiple develper management and reusable libraries -- packed or otherwise.  Again one issue that pops to mind, is it necessary to considder  managing a revised "library"  contorl and haveing to relink it  to applications whereever it was used? Where can I find such a white paper? 

[Sam_Sharp]

I don't know of any whitepapers discussing these issues in detail - at least none that are up-to-date but there are quite a few blog posts / community articles around that discuss the various topics you are talking about and a lot of it is down to developer/team preferences and processes. For example, at NI Week one year, I saw this presentation about software tools for LabVIEW which gave a lot of useful information: http://blog.jki.net/jki/niweek-2012-secret-sauce-tools-to-make-you-a-better-labview-developer-video-...

Within our team, we use SVN for source code control. VI Packages for all re-use libraries (with VIPM Pro for creating a local repository that all developers subscribe to) with the library source files also kept in SVN. We use Package Configuration Files for configuration management (keeping track of which versions of packages were used in the build) which is also stored with the project in SVN. For builds, we were able to justify a license for Deploy which does our release management, software versioning and auto-updating of software.

If we wanted to go a stage further, we might look at having a 'build machine' and use something like Jenkins to do clean/automated builds on a virtual machine / build server. At the moment it's a bit excessive.

[rickales1]

I found this NI webcast that is very good and addresses many if not all of my concerns.

https://ni.adobeconnect.com/p93x628suj7/?launcher=false&fcsContent=true&pbMode=normal