09-14-2020 03:25 PM
I've got an object oriented LabVIEW codebase in LabVIEW 2013, in which I've used a few objects and their methods to create a small testbench VI (data acquisition from a scale).
Here's the VI hierarchy:
The logging functionality (cluster elements to string, seen about 5 levels down on the right) is based on OpenG, but the overall hierarchy is less than 100 VIs, which I would expect to be fairly trivial to compile.
However, when I build this target, it processes all 3000 VIs in the project, which seems silly, given there's absolutely no dependencies there.
Do I need to factor these objects into their own libraries so that LabVIEW understands this?
09-15-2020 07:18 AM
In your build specification, go to the Additional Exclusions section. There are two options there you should select:
1. Remove unused polymorphic VI instances - OpenG has a ton of polymorphic VIs and this will remove the instances you don't use.
2. Remove unused members of project libraries - I don't think OpenG uses project libraries, but this is still a good way to weed out unused code in your executable.
09-15-2020 07:41 AM
What about the thousands of other VIs it processes from classes that are definitely not in the VI hierarchy? Do I need to manually exclude all of those?
09-15-2020 07:49 AM
@ijustlovemath wrote:
What about the thousands of other VIs it processes from classes that are definitely not in the VI hierarchy? Do I need to manually exclude all of those?
I *THINK* classes are treated as project libraries in this case. I will not swear to that though. But what is calling a class so that it is included in your dependencies? Those could also be showing up due to other things in your project or something that was dynamically called.
09-15-2020 08:18 AM
There's no dynamic calls in this code; I try to use that very sparingly, usually for async UI code. Also, those settings you mentioned were already set, so I don't think that's the issue.
The logging code mentioned is a member of the "Utilities" class I have, which has some general timekeeping, unit conversion, VI server code etc. Many other classes use "Utilities.lvclass" member functions, though I'm not sure why they would be affected just because this class is included in my build.
I'll try to factor this logging code into a completely separate library so that it's no longer dependent on this franken-class, perhaps that's the issue.
Again, it would be nice to know how the application builder does dependency resolution, because as you saw, the VI hierarchy is really quite small.
09-15-2020 08:24 AM
I Think all that's in dependencies are processed, and if some class has been loaded it'll stay there.
You could recreate the dependencies by removing them from the lvproj file (MAKE A COPY FIRST!) since it's just an XML file.
09-15-2020 08:31 AM
I'm not referring to the "Dependencies" project item, talking more generally about dependencies here. What's happening right now is that no matter what VIs are actually called, the build "processes" every single VI in the project, even ones entirely unrelated to the code that's being built.
09-16-2020 01:39 AM
09-16-2020 05:30 AM
@ijustlovemath wrote:
I'm not referring to the "Dependencies" project item, talking more generally about dependencies here. What's happening right now is that no matter what VIs are actually called, the build "processes" every single VI in the project, even ones entirely unrelated to the code that's being built.
But if a VI is in a class, all VI's in the class are included (I think).
I know for sure that no VIs in the class can't be broken (which is a bit annoying).
If a VI is in a child, all child VIs and parent VIs are probably included.
So it could depend on your hierarchy if indeed 'all' VIs are compiled. Do you know for sure all VIs are compiled? Or just a lot?
If parent classes have factories, they sometimes include their children as constants. So even if you don't load things dynamically, this would (by design) include all children and all child VIs.
This could escalate very rapidly! Use a VI, this includes the class, this includes the parent and grandparent, and all those VIs. The (grand) parent might have a factory, this will include all children. All classes used in those children will be included. All parents of those children will be included. And dependent classes in those will be included. All parents will be included. If they have factories... Soon the entire project will be included...
09-16-2020 07:26 AM
wiebe@CARYA wrote:If parent classes have factories, they sometimes include their children as constants. So even if you don't load things dynamically, this would (by design) include all children and all child VIs.
This could escalate very rapidly! Use a VI, this includes the class, this includes the parent and grandparent, and all those VIs. The (grand) parent might have a factory, this will include all children. All classes used in those children will be included. All parents of those children will be included. And dependent classes in those will be included. All parents will be included. If they have factories... Soon the entire project will be included...
This is where a plugin architecture with PPLs become invaluable. I bit of a learning curve, but well worth it.