PPL build process with lvlib Dependencies with *.mnu

[PBD_ctrl]

I have a PPL that I built that depends on NI_LVConfig.lvlib.  The PPL always seems to grab config.mnu from NI_LVConfig.lvlib and include it in the final PPL.  Typically this wouldn't be a major issue but when I went to build the next level of packages that are dependent on this package they throw an error 7 and complain about the config.mnu.  To get around the I modified my LabVIEW install and pulled the config.mnu from NI_LVConfig.lvlib.  After doing this config.mnu no longer shows up in my PPL.

While I do have a solution I am curious if this is expected behavoir and ask why NI_LVConfig.lvlib contains config.mnu in the first place?  I hate modifying a LabVIEW install...

[yea_likethecity]

PBD,

I'd like to confirm my understanding of the behavior you're seeing. It sounds like you're building a PPL which is then being used in a larger installation. When you build the PPL, it calls for the config.mnu file and pulls it successfully from the NI_LVConfig.lvlib. When you build the larger installation, it is unable to locate the config.mnu file and throws error 7 (file not found). Also, it looks like the mnu files define what tools are in palettes.

[PBD_ctrl]

You are understanding the problem correctly.

              -Pat

[yea_likethecity]

The PPL build doesn't move the config.mnu file around, does it? Like it just references it, it doesn't include a copy in the PPL, right?

[PBD_ctrl]

How would I be able to tell if it is encapsulated in the PPL or just externally linked?  I would expect that if it is pulling the rest of LV_Config.lvlib into the PPL that it would also bring in the mnu because it is a LabVIEW file. I could be wrong about this I am not entirely sure how it handles *.mnu's I try to avoid including them in my PPLs.

[yea_likethecity]

Pat,

I'm going to link a community example that illustrates pretty well the PPL structure, dependencies, and some notes on use. I'm also going to link a white paper dealing specifically with PPL use caveats and recommendations, plus one more that goes into detail about nested libraries and dependencies.

Packed Project Library Pitfalls

https://decibel.ni.com/content/docs/DOC-20274

Caveats and Recommendatoins for Packed Project Libraries

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/caveats_recommend_packed/

Packed Project Libraries - Part 2

http://labviewjournal.com/2011/10/packed-project-libraries-part-2/#more-214

From my understanding, normally when you nest a PPL in another PPL it basically grabs all the dependencies and puts it in the PPL files. This can actually lead to problems with duplicated dependencies. What I suspect may be happening is since NI_LVConfig.lvlib is a system library, it does not store it and just references it. Then when you try to nest the library, it tries to grab the file but can't find it in the lower level library which may throw the error. Check in the lower level library dependecies and dig up the config.mnu file, right click and pick "Explore..." This will show you where that file is being stored. I suspect it will be in the LabVIEW system files.

[PBD_ctrl]

This issue really isn't resolved.  Thr problem lies in the LabVIEW install.  Because NI_LVConfig.lvlib contains a referance to an MNU and an MNU cannot be encapulsalted within a PPL any PPLs that is going to include try and include NI_LVConfig.lvlib will also include the MNU.  This becomes a problem because the MNU's paths are not modified during the build process and so have become invalid.

My workaround for this is to modify the LabVIEW install and remove the MNU referance from NI_LVConfig.lvlib.

The reason why I made this post in the first place was to call out the negative implications of including MNUs in lvlibs with the hope that LabVIEW would no longer ship with them.

[yea_likethecity]

Pat,

I may have misunderstood the original issue. It sounds like when you build a library which includes functions from NI_LVConfig.lvlib, it includes the MNU file in your PPL for some reason. This doesn't cause too many issues, except that when you try to include that library in a larger library, you get dependency errors. I've built a PPL with components from NI_LVConfig.lvlib and I'm not seeing this issue. Are you including the NI_LVConfig.lvlib library itself in your PPL? Or am I misunderstanding the issue? If you are including the NI_LVConfig.lvlib library in your PPL build, you shouldn't need to do that. Since NI_LVConfig.lvlib is a default LabVIEW library, it is distributed with any LabVIEW distribution or Run-Time Engine. You should be able to reference functions from it without including the whole thing in your PPL.

[PBD_ctrl]

I have been including NI_LVConfig.lvlib within my PPL.  I believe this is necessary because I intend to distribute the PPL within a VIPM package installed in vi.lib and have it function within the run time environment.  If I build the PPL and exclude external lvlibs will it still open without error if it's relative path to the excluded external lvlibs change?  If I remeber correctly it does open with an error which forced me to include the external lvlibs.

[YinhuiChen]

Pat,

I started to use PPL recently and had the same issue as yours. Here is how it was solved for me,

Make sure to check Build Spec-> Additional Exclusion->Remove unused members of project libraries.

LabVIEW does not build the link to the *.mnu file or any other file that is not compiler-able when building the PPL. I believe this option is checked by default.

I noticed that some of the system libraries like the database toolkit are locked, removing the *.mnu from the library will not work in this case.

YChen