Solution Builder is a tool for building LabVIEW project build specifications in the correct order and, when some of those build specifications generate Packed Project Libraries (PPL, which have a .lvlibp extension), replacement are made in memory to allow dependent components to relink to build output instead of the original source.

• List of Features
• Minimum Compatible LabVIEW Version
• Use Case
• Usage
• How to Build
• How to Test
• Contributions (must read prior to PR submission)
• Known Issues

LabVIEW 2019 SP1 - Solution Builder uses a VI Server method introduced in LabVIEW 2019 to replace project items in memory, and benefits from improvements made to SP1 for in-memory replacement.

This tool is maintained using:

* These modules only installed to test multi-target build support and are not required for the tool to work as expected.

** The CLI package is only a necessary if you plan to build and use the LabVIEW CLI feature.

Source files are commonly organized by Component containing all related files and functionality. Dependencies for source files can span across components given that all the source is on disk when pulling a Git Repo.

The following example shows the file structure of source files.

MyAppRepo
└── obj/
└── releases/
└── src/Component A/
	└── myProjectA.lvproj
	└── CompA.lvlib
	└── myProgram.vi (CompA.lvlib:myProgram.vi)

MyAppRepo
└── obj/
└── releases/
└── src/Component B/
	└── myProjectB.lvproj
	└── CompB.lvlib
	└── myFunction.vi (CompB.lvlib:myFunction.vi)

Where CompA.lvlib:myProgram.vi calls and depends on CompB.lvlib:myFunction.vi. Loading both of these source VIs from disks succeeds.

The following example shows the structure of the LabVIEW project files.

└── My Computer
    └── CompA.lvlib
        └── myProgram.vi (CompA.lvlib:myProgram.vi)
    └── Dependencies
        └── CompB.lvlib
            └── myFunction.vi (CompB.lvlib:myFunction.vi)
    └── Build Specifications
        └── ComponentA (Packed Library)

└── My Computer
    └── CompB.lvlib
        └── myFunction.vi (CompB.lvlib:myFunction.vi)
    └── Dependencies
    └── Build Specifications
        └── ComponentB (Packed Library)
 
 

Where the project Build Specifications have the additional Exclusions as follows:

• Disconnect type definitions
• Remove unused polymorphic VI instances
• Remove unused members of project libraries
• Exclude dependent packed libraries
• Exclude dependent shared libraries

Using the current LabVIEW Application Builder, the build results are not in the desired state because the build results are as follows:

MyAppRepo
└── obj/
	└── CompA.lvlibp
		└── myProgram.vi (CompA.lvlibp:myProgram.vi)
		└── CompB.lvlib (CompA.lvlibp:CompB.lvlib)
			└── myFunction.vi (CompA.lvlibp:CompB.lvlib:myFunction.vi)
└── src/Component A/

MyAppRepo
└── obj/
	└── CompB.lvlibp
		└── myProgram.vi (CompB.lvlibp:myFunction.vi)
└── src/Component B/
 
 

Where Component B is correctly built because it has not dependencies, but notice that Component A pulled in its own copy of its dependency where CompA.lvlibp:myProgram.vi calls and depends on CompA.lvlibp:CompB.lvlib:myFunction.vi which is not what we want.

Note: The exception exists when this is the desired state for shared helper code that, for isolution from revisional and breaking changes, we do want to pull in that namespaced copy.

Instead, for major components that are versioned like in our example, the desired state is that when Component A builds it switches its dependency to the built packed libary of Component B at build-time resulting in the following:

MyAppRepo
└── obj/
	└── CompA.lvlibp
		└── myProgram.vi (CompA.lvlibp:myProgram.vi) -- depends on -->
└── src/Component A/

MyAppRepo
└── obj/
	└── CompB.lvlibp
		└── myFunction.vi (CompB.lvlibp:myFunction.vi)
└── src/Component B/

Where CompA.lvlibp:myProgram.vi calls and depends on CompB.lvlibp:myFunction.vi looking similar to source namespacing and component boundaries.

To accomplish the correct build result the build needs to calculate the build order and then replace links to build results before building the next caller in the following fashion.

1. Analyze projects and their dependencies
2. Order the build specifications bottom-up
3. Build the first items with no dependencies
4. Find the next level that needs to build, whose dependencies have been built
5. Relink that next level to depend on the built components
6. Build that next level
7. Repeat the process from step 3 until there is nothing left to build.

The following example shows the structure of the LabVIEW project files and result when a single project contains multiple libraries that depend on each other and produce separate PPLs.

└── My Computer
    └── CompA.lvlib
        └── myProgram.vi (CompA.lvlib:myProgram.vi)
    └── subCompC.lvlib
        └── myFunctionC.vi (subCompC.lvlib:myFunctionC.vi)
    └── subCompD.lvlib
        └── myFunctionD.vi (subCompD.lvlib:myFunctionD.vi)
    └── Dependencies
        └── CompB.lvlib
            └── myFunction.vi (CompB.lvlib:myFunction.vi)
    └── Build Specifications
        └── ComponentA (Packed Library)
        └── subComponentC (Packed Library)
        └── subComponentD (Packed Library)

MyAppRepo
└── obj/
	└── CompA.lvlibp
		└── myProgram.vi (CompA.lvlibp:myProgram.vi)
	└── subCompC.lvlibp
		└── myFunctionC.vi (subCompC.lvlibp:myFunctionC.vi)
	└── subCompD.lvlibp
		└── myFunctionD.vi (subCompD.lvlibp:myFunctionD.vi)
└── src/Component A/
└── src/subComponent C/
└── src/subComponent D/

Solution Builder can be operated on through its user interface or by command-line.

• Path : Path to the file or folder to execute on. The following are accepted:

• Log file path : Path to the file containing log information regarding decisions to rebuild an item or skip it because a previous build was deemed sufficient.

• Preview : Will run the algorithm to determine the dependency build order, but will not execute the projects' build specification.

• Force Rebuild : Ignores the incremental build information from previous runs and rebuilds everything.

• Cancel Build : Aborts a build, but waits for the current item to complete.

• Results Table : Displays the found build specification outputs and show their build status.

• Error/Warning Bar : Return any build errors or status from the utility.

When using a solution file, the following is an example valid content tags:

<Solution>
	<ProjectPath></ProjectPath>
	<AddPackedLib></AddPackedLib>
	<Version></Version>
</Solution>

	<ProjectPath>C:\This\Is\A Windows Absolute Path.lvproj</ProjectPath>
	<ProjectPath>Relative\Path.lvproj</ProjectPath>
	<ProjectPath>..\Relative\Path.lvproj</ProjectPath>
	<ProjectPath>Relate Path/Forward Slash.lvproj</ProjectPath>
	<ProjectPath>../Relate Path/Forward Slash.lvproj</ProjectPath>
	<ProjectPath>/C/Linux/Absolute/Path.lvproj</ProjectPath>

	<AddPackedLib>PATH=Relative\Path.lvlibp</AddPackedLib>  # Will implicitly append "::NAME=Path.lvlib::TARGET=My Computer" 
	<AddPackedLib>PATH=..\Relative\Path.lvlibp::NAME=OriginalName.lvlib</AddPackedLib>  # Will implicitly append "::TARGET=My Computer" 
	<AddPackedLib>PATH=..\Relative\OtherPath.lvlibp::NAME=OriginalName.lvlib::TARGET=cRIO-9082</AddPackedLib>

	<Version>1.2</Version>
	<Version>1.2.3</Version>
	<Version>1.2.3.4</Version>

Begin by either downloading the latest Release or building the latest source, and the following then Enabling the LabVIEW CLI.

Invoking the CLI requires a command similar to the following (See List of accepted arguments for details):

:> LabVIEWCLI -OperationName BuildSolution -Path <path_to_some_project>\myProject.lvproj -LogFile <path_to_some_log>\file.log -AddPackedLib PATH=<path_to_some_ppl>\TheFile.lvlibp::NAME=TheOriginalLib.lvlib::TARGET=cRIO-9068 -Rebuild -ActiveTarget "My Computer" -ActiveTarget cRIO-9082 -KeepSplitProjects -Version 1.2.3.4

To invoke the CLI with a custom path to the BuildSolution operation using the -AdditionalOperationDirectory parameter detailed in Enabling the LabVIEW CLI Option 2.

Begin by either downloading the latest Release or building the latest source.

Note: It's important to close LabVIEW between invocations of the tool from the command-line since LabVIEW only reads command-line arguments on launch. To read the new command-line arguments, LabVIEW must close and relaunch with the new arguments. To help with exiting LabVIEW between calls, use the -Quiet option.

Invoking the packed tool from its built LLB requires a command similar to the following (See List of accepted arguments for details):

Path_to_repo> "C:\program files\national instruments\LabVIEW 2020\LabVIEW.exe" <path_to_llb_obj>\SolutionBuilder.llb\SolutionBuilder.vi -- -Path <path_to_some_project>\myProject.lvproj -LogFile <path_to_some_log>\file.log -Quiet -AddPackedLib PATH=<path_to_some_ppl>\TheFile.lvlibp::NAME=TheOriginalLib.lvlib::TARGET=cRIO-9068 -Rebuild -ActiveTarget "My Computer" -ActiveTarget cRIO-9082 -KeepSplitProjects -Version 1.2.3.4

When using either the LabVIEW CLI or directly using the command-line, the following arguments are accepted:

Solution Builder supports some incremental builds. This means that the tool will do its best to determine if a Project Build Specification needs to rebuild. The algorithm to determine if an build specifation needs to rebuild is as follows:

1. The Rebuild flag is set to true either from the command line or from the UI.
2. The destination of the build output does not exist.
3. The source files associated with the build specification have changed.
4. Static dependencies of the source files associated with the build specification have changed.

Note: the tool determines that a source file has changed if the MD5 hash of a file does not match its previous hash. Hashes from previous runs are stored in a .incrb file next to the project/solution file.

Source distribution currently do not know before they build which source files they are associated with. As a result, source distributions always rebuild.

The owning LabVIEW project contains a build specification to create a self-contained LLB.

1. Open the project
2. Expand the Build Specification entry in the project and build the component you want. Attempting to build the LabVIEW CLI build specification requires NI LabVIEW Command Line Interface to be installed; building the other components without the CLI installed is supported.

Once built, the built binaries will be located in the \LVSolutionBuilder\obj folder. The contents of the obj directory are as follows:

There are 2 ways of invoking Solution Builder with the LabVIEW CLI. The first involves copying the built files to the CLI's known location (option 1). The second involves invoking the CLI with a custom path telling it where the built binaries can be found (option 2).

Option 1: After following the instructions in the How to build section:

1. Copy the obj\LabVIEW CLI folder to <program_files>\National Instruments\Shared to merge the built folder with the existing folder installed by LabVIEW.
2. Copy the obj\SolutionBuilder.llb to the new <program_files>\National Instruments\Shared\LabVIEW CLI\Operations\BuildSolution folder.
   • Note: To support multiple versions of LabVIEW, place the SolutionBuilder.llb inside a year-version subfolder. For example, .\BuildSolution\2020\SolutionBuilder.llb, etc. If no matching year-version subfolder is found, the CLI will look for the LLB in the root .\BuildSolution folder.

Option 2: Simply invoke the CLI while adding the following argument: -AdditionalOperationDirectory "<path_to_llb_obj>\LabVIEW CLI\Operations\BuildSolution".

Open and run /src/_test/RunTheTests.vi then verify that the results all pass.

Note: To avoid the issue listed in the Known Issues, run the main test VI directly instead of from the owning project.

This project welcomes Issues, Discussions, and Pull Requests. Review the CONTRIBUTING document for information.

Error 1370 occurred at an unidentified location
Possible reason(s):
LabVIEW: (Hex 0x55A) The selected build failed to complete.