This is related to another issue I recently submitted, but I found when I run the LV Solution Builder with the slnfile method and point at a project with a single build spec for an executable, 4 project items are generated. Only one of these project items has dependencies listed, and it is also the only item with a source file listed.
I have found via testing that the way SubGenerateListToOrder.vi currently parses project items and adds them to the ordering map results in one of the project items without a source file to be used for my build spec, and the build ends up failing after all libraries have been swapped. This issue was resolved locally by adding code that ensured the project item with a source file (which was the top-level VI included in my build specification), but I wanted to report this as an issue in case one build spec generating four project items would be considered unexpected behavior (especially with 3/4 items not containing a source file).
This is related to another issue I recently submitted, but I found when I run the LV Solution Builder with the slnfile method and point at a project with a single build spec for an executable, 4 project items are generated. Only one of these project items has dependencies listed, and it is also the only item with a source file listed.
I have found via testing that the way SubGenerateListToOrder.vi currently parses project items and adds them to the ordering map results in one of the project items without a source file to be used for my build spec, and the build ends up failing after all libraries have been swapped. This issue was resolved locally by adding code that ensured the project item with a source file (which was the top-level VI included in my build specification), but I wanted to report this as an issue in case one build spec generating four project items would be considered unexpected behavior (especially with 3/4 items not containing a source file).