How to export code for end users that is cleaned

[billko]

---

@JÞB wrote:

And now for some additional advice:

Take the opportunity to create documentation and examples in the source lvproj for each lvlib that you will build into a lvlibp.  Then even find a nice location to install your example code to with you lvlibp installer.  It's a few minutes for the owning developer that will pay off at least 100:1 on the rest of the dementia [EDIT: DEVELOPMENT. sometimes automatic corrections are soooo true] team's code effort, debug, and integration time.

Just believe me now and thank me later. 😀

---

I implemented an entire IDD from the ground up.  It was super-complicated with different libraries for each system component, but because the documents I made contained an explanation for provided examples on how to use them as well as a walkthrough on how to create a new command from scratch, the next developer who needed to add a new command to the IDD implementation and use it said it was trivial because the documentation was so thorough.  (And I looked at the new command and it was implemented exactly as the documentation said it should be.)

[MaSta]

---

@JÞB wrote:

And now for some additional advice:

Take the opportunity to create documentation and examples in the source lvproj for each lvlib that you will build into a lvlibp.  Then even find a nice location to install your example code to with you lvlibp installer.  It's a few minutes for the owning developer that will pay off at least 100:1 on the rest of the dementia [EDIT: DEVELOPMENT. sometimes automatic corrections are soooo true] team's code effort, debug, and integration time.

---

Yes, of course, that's what we would do. Still have to find out the best way for installation. NIPKG, VIPM or EXE.

[wiebe@CARYA]

I've never used this, but you can make a build specification of the type "source distribution":

You should be able to select what gets copied to the distribution.

You should also be able to select items that get password protected, or that get the BD removed (the FP can also be removed).

That's potentially a lot of maintenance, but it seems like the intended purpose of a source distribution build specification.

You can add a pre and\or post build action, to do custom things the build spec doesn't support. E.g. zipping the resulting build, optionally move or copy the zip, in a post build action is quite nice.

[JÞB]

---

@MaSta wrote:

---

@JÞB wrote:

And now for some additional advice:

Take the opportunity to create documentation and examples in the source lvproj for each lvlib that you will build into a lvlibp.  Then even find a nice location to install your example code to with you lvlibp installer.  It's a few minutes for the owning developer that will pay off at least 100:1 on the rest of the dementia [EDIT: DEVELOPMENT. sometimes automatic corrections are soooo true] team's code effort, debug, and integration time.

---

Yes, of course, that's what we would do. Still have to find out the best way for installation. NIPKG, VIPM or EXE.

---

Just create 2 build specifications in the source project 

The PPL spec and the installer that installs the PPL and the additional example vi to the example location 

[MaSta]

Digging into this is a hot mess. Seriously. The goal is to disseminate a package of VIs for customers which would appear in the block diagram context menu under the instrument library. Nothing special. But how to do it the best way? 

---

So one of the suggested ways was to create an LVLIB. The important thing is that an LVLIB doesn't contain any VI, like an LLB. So it's also important where you put the LVLIB and where the source files are. Since the LVLIB isn't the exported product, but an intermediate stage, you would put it along with the source files. 

Point 1: you add organized files and folder to "My computer" or directly into the LVLIB. When adding first to My Compter and then adding to the LVLIB, they get moved, not copied. Doh!

Point 2: once linked to an LVLBI, LV would save all files (we got, like, 240 sub VIs) as "linked to the lib" and not just by copying them to the target folder, it will save the source files! You gotta know what you do, because there is no way to batch-unlink them in case you want to revert. So it's good to have a backup of the source files.

Point 3: in order to have a custom palette file (*.mnu) for your package you have to create one. But when? One way would be BEFORE putting the files/folders into the LVLIB. You cannot use the lib itself to be linked link in palette editor. Another is to put the MNU file into the lib, but then you gotta have one already. You could later link the MNU file in the lib to a new sub palette which would give you another MNU -->???

Side point: you can only edit the LV palette when any VI is open. Why? I would have expected to opt for the default palette.

---

Another suggestion was to create a packed library, because that can give you stripped block diagrams, hidden sub VIs as "Private" and you can even add a palette. So the file/folder structure in the LVLIBP is supposed to be same as in the LVLIB, but it's not. If you edit your LV palette and add the MNU file to the LVLIBP, you can set to use the MNU file as default palette. But how to use? I create the LVLIBP with the MNU in, put the LVLIBP into a subfolder under \instr.lib it wouldn't show up in the context menu.

The craziest thing that the LVLIBP becomes part of the project. As soon as you open the project next time, LV comes up with a circle error caused by the same MNU file allegedly loaded multiple times, showing you the paths of the MNUs to be in the subfolder structure of the LVLIBP. But if you open the tree view of the lib, there are no MNUs in the subfolders. There is only one MNU in the main folder. OK, something went wrong, so start again.

There is a tutorial. It says "1. Open the driver's associated LabVIEW project folder located in <LabVIEW>\instr.lib.". That's odd, because the folder under \instr.lib is supposed to be the target folder, not my source folder. However, let's do this. I don't know how you create single MNUs for every subfolder, because you would add the main folder and the VIs in subfolder would automatically appear.

Then in step 10. you are instructed to create a new MNU. You cannot overwrite an existing one. I don't get it. 

[MaSta]

---

wiebe@CARYA wrote:

I've never used this, but you can make a build specification of the type "source distribution":

You should be able to select what gets copied to the distribution.

You should also be able to select items that get password protected, or that get the BD removed (the FP can also be removed).

You can add a pre and\or post build action, to do custom things the build spec doesn't support. E.g. zipping the resulting build, optionally move or copy the zip, in a post build action is quite nice.

---

It doesn't work for me. I have LV 2021. I create a blank new project. I add the folder structure that contains the VIs. I right-click "Build specifications" to either create the source distribution or the packed library and LV simply does nothing. Restart LV, no chance. Like the app builder is dead.

[wiebe@CARYA]

---

@MaSta wrote:

---

wiebe@CARYA wrote:

I've never used this, but you can make a build specification of the type "source distribution":

You should be able to select what gets copied to the distribution.

You should also be able to select items that get password protected, or that get the BD removed (the FP can also be removed).

You can add a pre and\or post build action, to do custom things the build spec doesn't support. E.g. zipping the resulting build, optionally move or copy the zip, in a post build action is quite nice.

---

It doesn't work for me. I have LV 2021. I create a blank new project. I add the folder structure that contains the VIs. I right-click "Build specifications" to either create the source distribution or the packed library and LV simply does nothing. Restart LV, no chance. Like the app builder is dead.

---

I don't think you need the application builder for making a source distribution. Maybe not even for making a PPL.

Not sure how you should fix it (another topic), but it does seem like a showstopper.

It could be that the first time this is done the entire vi.lib is mass compiled. It might take looong. Clearing the compiled cache for builds might help (unless there's nothing in it).

[MaSta]

@wiebe@CARYA: I had to restart LabVIEW, then the (app) builder would start again.  

By the way, I had never tried the export method "Source Distribution", but if I use the option to remove the block diagram, the build fails on a LV class sub vi.

[MaSta]

Futher tips and help wanted. What I did:

• Created a new project
• Added files/folder, including dir.mnu
• Turned that file/folder structure into an LVLIB -> the structure shown in the project tree view is fine, all folder names correct
• Created a build specifiction for "Packed library", set the LVLIB as main lib and the dir.mnu as palette file
• Compiled the LVLIBP. After saving and closing the project, LV comes up with palette loading error (circulation) and shows me the paths in the LVLIBP to allegedly have all the same dir.mnu file -> if I open the LVLIBP it shows just fine in the tree view. Just one dir.mnu, all folder names OK
• I then open a blank VI and go to palette editor. In the editor I create a new subpalette and link it to the dir.mnu in the LVLIBP -> the result is that subfolder names in the context menu are messed up

How to solve that? My best guess is to actually create MNU files for every subfolder, but with different name, as suggest here.  

[GerdW]

Hi MaSta,

---

@MaSta wrote:

• Added files/folder, including dir.mnu
• Turned that file/folder structure into an LVLIB -> the structure shown in the project tree view is fine, all folder names correct
• Created a build specifiction for "Packed library", set the LVLIB as main lib and the dir.mnu as palette file

---

Why do you add the mnu file to the lvlib? (IMHO the mnu file is related to the LabVIEW IDE and does not belong (in)to your lvlib…)

Where do you set the mnu file as "palette file" in the BuildSpec? (I don't see this option in LV2019…)

When you want to provide an "installation/distribution package" for your lvlib then you may look for that in VIPM.

VIPM will handle the installation of lvlibs/VIs into the vi.lib and will also be able to place a mnu file in the correct place: