Sub-projects /Cross-project builds

[Mads]

Make projects aware of the content of other projects so that you can join multiple projects into a master project. You should then be able to access the contents of each sub-project from the master project.

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

Scenario: You have multiple projects and want to build applications in each of them and then create an installer that includes all these applications.

If everything was in the same project you could just select all the build specifications and build everything in one go, but today's solution is much more cumbersome: Manually build each of the projects and then have a separate installer project that is based on auto-populating folders pointing to the outputs of the sub-projects...Or - create code that autopmates it for you...Or - forget about having spearate projects and put everything in the same project...(remember to avoid any VI naming conflicts).

[PaulLotz]

I sent a suggestion to NI that addresses the same issue:

Introduce subprojects or packages as hierarchical elements in projects 

Please introduce the ability to incorporate a project as a subproject or package within another project.  This functionality is critical for effective code reuse and maintainability.

 

As an example of why this is important, I offer the following:

 

We have created a class ComponentData and a number of associated classes and other files.  We neatly package these in a file structure on disk and in virtual folders in a LabVIEW project.  [Note that we use virtual folders since in principle, at least, we can use a given class in different ways in different projects.]

 

Now ComponentData and its associated classes are common classes that we created precisely for reuse between components, each of which we define in its own project.  We encounter an issue when we attempt to reuse ComponentData and its associated elements, however.

 

We can create a project (call it Component.lvproj) and attempt to incorporate this project into a new project for a particular component.  This, however, is not useful, since it merely creates a link to Component.lvproj and does not import any of the elements of Component.lvproj into the larger project.

 

Alternatively, we can copy the virtual folder hierarchy containing ComponentData and its associated classes and other files into the new project.  This does explicitly import the elements, but simply copying virtual folders in this manner does not support maintenance needs.  While it is true that if we edit the class definition in one project it will update in all callers (each class correctly has a single definition), unfortunately other changes (moving or renaming virtual folders, moving elements between folders, and so on) we make in one project will not reflect in other projects.  This approach is wrong in principle as well as in practice because we end up with multiple independent definitions of the same thing.  (The definition should exist in only one place.)

 

What should happen is that we should be able to define a subproject or package and import it into a project, such that:

1)      the package elements are now accessible in the larger project (portable)

2)      any changes to the subproject or package will appear in all referencing projects (single definition)

3)      any part of a particular package may itself become a subpackage itself (hierarchical)

 

[Note: As I write I realize that using autopopulating folders (which are inappropriate for the reason mentioned above) can satisfy 1 and 2 to some extent but not 3.]

 

A wonderful example of what I propose exists in a UML design tool we use called Enterprise Architect (and almost certainly within many UML tools).  Within a given project we define a hierarchical layer of packages.  (In UML each package, like a LabVIEW project, has an XML definition.)  At whichever level we choose, we can choose to add a package to version control.  (In our case the tool interfaces to the CollabNet client to a Subversion repository.  The CollabNet client is open-source, free, and certified, by the way, and is a much better client than the horrible PushOK client currently available for Subversion connections from LabVIEW).  When we want to reuse a package in another project, we simply pick the package we want from version control.  (We can select a lower-level package if we don’t want the entire hierarchy.)  To make sure the package is up to date we simply invoke a command to update the package from the pop-up menu.  This works quite well.

 

Summary: The ability to import subprojects or packages in a hierarchical manner is critical for effective code reuse and maintenance.  We consider this a quite essential feature of any project paradigm in any software development environment.  The benefits to users (and therefore to NI) are many and the drawbacks are, well, none.  Please ensure this becomes a feature of a version of LabVIEW in the very near future.

[PaulLotz]

I reviewed some posts on LAVA and some documents on ni.com.

It seems (my interpretations):

1) There is pretty good (though not universal) agreement on LAVA that the use of auto-populating folders is not the best approach for this purpose, primarily because auto-populating folders don't mesh well with libraries.

2) There is a mechanism already in place that appears to meet all three of my requirements above.  That is to use .lvlib files.  (The only .lvlib files I have used to date are those created automatically by LabVIEW when I create shared variables.  I had used .llb files but these have distinct characteristics not suitable for my purposes.  I realized I didn't know much about .lvlib files. )  Anyway, .lvlib files seem at least in principle to do what I want to do, so I will explore using these.  (I just made my first attempt now, so I don't have much to report yet!  I'm sure there are others out there who can comment more intelligently on .lvlibs than I!)

The following Tutorial does detail the differences between the various library types pretty well:

Best Practices for Sharing and Reusing LabVIEW Code