Actor PPLs for both RT and Windows

[Cy.Rybicki]

My company is going through the process of creating a set of reusable Actor PPLs, and we would like to have these available on both RT and Windows targets. This isn't too bad for the top level Actor (built based on the Actor Framework As PPL shipping example). We added a RT target to the project, created as copy of the AF library on that target and then built a second PPL for RT.

However, we're running into problems once we try to do the same for child and grandchild actors. In addition to placing a RT target into the child actor project, we must also switch the inheritance of the actor, all of its messages, and any other dependent PPLs to the RT version. This is obviously rather time consuming and not a great solution.

Is there an easier way to switch between Windows and RT? Or is there a better approach for creating a code base that can be used on both platforms?

[Taggart]

I am not an expert on PPLs so I may be off here, if so someone please correct me.

Sounds like you need some sort of automated build system.

Scripting ought to be able to do all the moving around for you. Create a one-click Build.vi that does all the scripting and then invokes the Build API.

You might also look into something like the MGI Solution Explorer to manage all the different builds.

If you really wanted to get fancy you could implement some continuous integration using GitLab CI or Jenkins.

---

@Cy.Rybicki wrote:

Is there an easier way to switch between Windows and RT? Or is there a better approach for creating a code base that can be used on both platforms?

---

I think once you go to PPLs, you have no choice but to have an RT version and Windows version since it is all compiled.

[cbutcher]

Short version: Use the Application Builder API to programmatically build your PPLs.

Longer version: In 2019 you're looking for 

(PC): ...\vi.lib\AppBuilder\AB_API\PPL\Create New Packed Library.vi

(RT): ...\vi.lib\AppBuilder\AB_API\DPPL\Create New Deployable Packed Library.vi

I'd guess the same may be true for other targets, but I've only tested using a cRIO-9045.

Then you need to set the destination path appropriately (Set Primary Destination Path for PC, Set Local Destination Path for RT), call whichever other related subVIs you want to customise the build spec (debug/release, version, description, author name, etc...) then call Commit Build Settings.vi and Build.vi followed by Close.vi.

I made use of Directory Junctions on Windows to rearrange paths as needed at Build time (this requires an absolute path, but not Admin rights).

If you have general questions, feel free to ask here, if you want more specific examples please message me because I don't want to widely share my build code just yet.

Edit: I also remembered (but forgot to previously mention) that I use blank template projects for each build (nothing there except the target I'm building for) to simplify adding code via scripting.

[Cy.Rybicki]

I was hoping to avoid using VI scripting but it sounds like it might be necessary. Haven't looked into MGI Solution Explorer at all but I'll check that out as well.

[Cy.Rybicki]

---

@cbutcher wrote:

Short version: Use the Application Builder API to programmatically build your PPLs.

---

Using the Application Builder API is a good idea to automate some of this, but I don't think it can handle changing PPLs in the project dependencies from their Windows to RT version and vice versa. It's looking like VI scripting might be the only option for that.

[Taggart]

It's not as bad as you think.

[cbutcher]

I tried adding specific dependencies using scripting (to the blank project, in reverse order iirc) previously but that caused me more problems than it offered solutions.

I'll check my build system more closely (the thing that calls LabVIEW, not the LabVIEW bit, which definitely doesn't add dependencies or do anything special there anymore) but I think it's only the directory junction that handles this for me.

Note that a symbolic directory link is not the same (at least on Windows). LabVIEW will resolve a symbolic link, but a directory junction is two different paths to the same actual place.

In my case I have

C:\LabVIEW Sources\myproject\<source files> and

C:\LabVIEW Sources\PPLs\{Windows,cRIO,Current} (and some subfolders for e.g. release, debug, 32/64 bits) and Current is adjusted to point to whichever I'm building at the time.

My build system has very little scripting - and most of that is generating a VI and adding it to the library to give a PPL version number based on Git tags. I don't commit this file into the repository, so it doesn't exist in the source, but the builder repository has a template used for the scripting.

[Taggart]

Here's a good place to get started (courtesy of Fab!)

https://delacor.com/5-steps-to-become-a-vi-scripting-ninja/

[Taggart]

---

@cbutcher wrote:

My build system has very little scripting - and most of that is generating a VI and adding it to the library to give a PPL version number based on Git tags. I don't commit this file into the repository, so it doesn't exist in the source, but the builder repository has a template used for the scripting.

---

Does this mean you don't use the built-in versioning (ie setting the version on the build spec - which you can then see in Windows Explorer)? From your description it sounds like  you just have a VI in the ppl that outputs the version as a string? Am I understanding that correctly?

[Cy.Rybicki]

---

@Taggart wrote:

Here's a good place to get started (courtesy of Fab!)

https://delacor.com/5-steps-to-become-a-vi-scripting-ninja/

---

Thanks! I will check that out.