Building dependent PPLs across multiple targets (Windows, cRIO)

[cbutcher]

I started with a somewhat rambling post here: Building dependent PPLs on cRIO. That post was in an Actor Framework on cRIO specific subforum because it began with compiling AF, but I think my questions are now more general, so I'm posting here.

I'm going to use bullet points to try and break up a set of observations/facts/hopes/opinions that might otherwise be a little difficult to read.

• I'm building a set of PPLs with dependencies in a single direction.
• Some of these PPLs, in addition to being used on Windows (currently in the development environment, eventually planning to build an exe), must be deployed to cRIO.
• cRIO PPLs must be built separately from the same library as a PPL on Windows (different OS, different target)
• cRIO PPLs must depend on their own cRIO PPLs (i.e. if B.lvlib{,p} depends on A.lvlibp, the RT version of B must depend on the RT version of A. The Windows version of B depends on the Windows version of A)
• As a result, when I need a library on both RT and Windows, all of the nested dependencies must be built for each platform
• I want to only have a single set of source code for any libraries on both platforms (libraries on both platforms are by definition not platform specific)
• Some libraries (Actor Framework principally) are in <vi.lib>. I don't want to modify the contents of vi.lib (at least, if I make modifications, they should be reversed immediately after building)
• Copying the sources out of vi.lib seems to wreak havoc. I'm not sure if the project providers and AF_Debug.lvlib are adding to my misery here with cross-linking/conflicts. It doesn't seem to be a practical solution to that specific problem

Some questions:

1. In the A, B example above, B.lvlib in B.lvproj on Win depends on A.lvlibp (Win). B-RT.lvproj contains the same B.lvlib, which depends on A.lvlibp (RT version). This essentially leads to two projects containing the same library, and loading from an unexpected path when changing project. Alternatively, I can switch the version of lvlibp at the expected path (but so far, only manually, before loading the project). This seems to quite frequently break my RT project and then cause LabVIEW (2017, 32-bit) to crash when opening the RT projects. The Windows projects appear to be fine. How should this be handled (the dependency on different versions of the same lvlibp, one per platform, not the crashing)
2. If I instead have a single project with two targets and drag the library (B) from target to target to build it, then the dependency (A) cannot be loaded on the second platform (wrong version). If I recall correctly, switching the file in the specific path then right clicking and choosing load solves this, but isn't ideal (it could I suppose be scripted). Is this a better(?) method?
3. DerrickB has posted a similar question at this link: Building PPLs for multiple platforms. Could someone answer that? I suspect it would help me lots! 😉
4. I had thought I'd seen some recent build tools being promoted at e.g. NIWeek 2018. However, BLT (Studio Bods) and Component Builder (Chris Cilino) both appear to not build/target PPLs (or that much in the way of cross-platform building. Perhaps I'm missing something). Are there other tools I should be looking towards?

Any advice is much appreciated.

[Mark_Yedinak]

First and foremost I would recommend that you look at using MGI's Solution Explorer. It really helps when building PPLs. It make life a lot easier. Secondly, I wold recommend that you set up a continuous integration system using something like Jenkins. When you start using PPLs you will need to rebuild often and something like Jenkins will help you to automate the process.

LV 2018 has an example project for building AF into a PPL. You will need this for your system. I have been told there is a bug in LV 2017 with building AF as a PPL. We switched to LV 2018 as a result of this.

What I think you will need to do is have your build environment setup so that you build your target dependent PPLs and include a prefix or postfix to the PPL name to designate which target it is for. Your code will probably need to use conditional disable structure to load the correct library for a given target. I have not attempted to do this myself but I will need to in the near future. I have had to place other code in conditional disable structures to load different code for specific targets but have don't that with PPLs yet. though I don't see why this wouldn't work. The VIs calls in the different case of the conditional disable structure would be the same but would be using the correct version of the PPL for the specific target. Your source code for the PPLs would be common, only your build specs and the name of the PPL would change for each target. This isn't the cleanest solution but I think it should work.