Leaderboard

Not really unless you want to build some very custom stuff into your executable itself. And you would need an executable that does not statically link to the OpenG ZIP library as at the time you start it up, it can not reference the shared library anywhere or the loading will fail and the executable is not executable. To me that sounds like a lot more trouble than it's worth and you have the same issue with NI Toolkits. If you make use of (for instance DAQmx functions) you have to make sure the DAQmx driver is installed onto the target before you can deploy an executable that makes use of it. The Pharlap ETS platform did include some means of deploying shared libraries directly together with VIs when you deployed the program from the project but that may have sounded like a cool thing initially when a Windows DLL was simply executable on Pharlap too, but nowadays most Windows DLLs won't load on Pharlap and have to be created specifically for the Pharlap ETS target. For non Windows like OSes like the NI Linux RT system, where the elf shared library is all but Greek for the Windows based LabVIEW environment, this is even more complicated.

The OpenG package file is simply a ZIP file in disguise, with an ini style package file (called spec) in the root that describes where the different file groups should go to in your LabVIEW installation and with restrictions for what version and platform they apply for. If you have 7-Zip installed you can right click on a *.ogp file and select 7-Zip->Open Archive. Then look in the directories for "File Group 8" and in there is the ogsetup.exe file. This is an Inno Setup file that installs the necessary packages into the correct NI Shared location for RT packages. I choose to do it this way as the files have to be installed in a location that has only write access when the process is evelated and rather than requiring the user to restart VIPM explicitly as admin (and trying to guess the correct location to write the files to from within a post install hook VI), I created an Inno Setup installer for the necessary files with an embedded manifest that requests elevation authorization from the user. After that and provided you have full cRIO support for NI Max for your target installed on your machine, you should be able to select the package in the Custom Software Install from within NI Max. Basically I choose to only extract the ogsetup.exe file into a LabVIEW 32-bit installation, since this is the only way to program LabVIEW RT programs anyway. I figured that the chance that someone would want to install SW packages to a RT target from a computer that is not used to program that target too, would be a very unlikely situation.

Here are some common files that could be helpful: The contribution guidelines are shown for pull requests: https://help.github.com/en/articles/setting-guidelines-for-repository-contributors LabVIEW versions, build instructions and the release process are commonly placed in a README file: https://help.github.com/en/articles/about-readmes The license can be managed in a similar fashion: https://help.github.com/en/articles/licensing-a-repository All of these files, if they exist, add to the GitHub experience. For example: https://github.com/microsoft/vscode