Hi all,
I think the answer to this is clearly "no," but that's never stopped me from asking before. When I build NI packages to distribute LabVIEW APIs to other users at my company, I first need to make a source distribution of my code since NI packages cannot directly include loose VIs but can include source distributions. My project that houses my source API code will generally have a top level Open and Close method and then several virtual folders and sub virtual folders organizing my various methods. I used to make my disk hierarchy match my project's virtual folder hierarchy, but I recently decided to experiment with using a flat disk hierarchy and just organizing the code in my project. I much prefer this because I never have to worry about the two going out of sync anymore (they're out of sync by design!) and because I thought I wouldn't really need to worry about how the code was organized on disk anyway. But an obvious shortcoming is that the "Preserve disk hierarchy" checkbox I used to rely on to organize my source distribution's folder hierarchy in the "Destinations" tab of the SD Properties window now doesn't work. All of the code in each virtual folder is flat in its destination directory when I build the SD because I've flattened the disk hierarchy. This is undesirable because once the source distribution is packaged and installed (let's say in user.lib), the folder hierarchy on disk is used to format the menu hierarchy, which is great for my users. I don't get that behavior anymore with a flat source code disk hierarchy.
1. For those who use flat disk hierarchies, do you build source distributions and just make a ton of destination directories and laboriously map individual VIs to those destinations? Is it wildly uncommon to use flat disk hierarchies? (I should say that when I say "flat", I really mean I'll have a folder for a class and all of its methods, for example.)
2. Am I being silly by using this code organization approach? I heard about it this NI Week at a presentation and liked the concept, but I worry about this key use case making it more problematic than helpful.
