Actor Framework Discussions
How to build a PPL including Actor classes, messages and AF Debug
Solved!
Hey Allen, the AF folder is still in vi.lib as I need to allow people to develop without forcing them to depend on my PPL. Updating that path per Christian's instruction did allow the message maker to see my PPL dependent actors as AF and make the message maker available via right click on the project item. My use case may be an edge case, but I intentionally want my dev team to be able to either use AF from vi.lib as it ships with LabVIEW, or be able to depend on the PPL in a local repository as a git submodule.
As others have alluded to, there are parts of the AF Message Maker Provider that identify actors by their ancestor inheritance path. If, for some reason, the path shown in Christian's screenshot is not found in the PPL, the MMP will fail. The top two reasons I can think of this happening are:
- You moved the AF lvlib out of the default folder location before the PPL gets built.
- You removed AFDebug as a dependency of AF. I've seen some developers do this and now, because all the files for AF are found within one directory, the extra relative paths are stripped away.
If you follow the instructions in Stephan's PDF, you can move the AF PPL around freely and everything (as far as scripting) works fine.
@jon_mcbee wrote:
I wrote a little tool to manage git interaction and PPL building, I bet I could add a feature to the tool swap between PPL based AF dev and non-PPL based AF dev
@jon_mcbee wrote:
I need to allow people to develop without forcing them to depend on my PPL. Updating that path per Christian's instruction did allow the message maker to see my PPL dependent actors as AF and make the message maker available via right click on the project item. My use case may be an edge case, but I intentionally want my dev team to be able to either use AF from vi.lib as it ships with LabVIEW, or be able to depend on the PPL in a local repository as a git submodule.
I'm curious about how this works and what's your use case for switching between the two. In my experience, going between PPLs (not just AF, but in any OOP-based project) and source at development time is a pain.
I agree with you, I just didnt do a good job explaining. We have very large projects that need the PPL dependency stack, but we also have very small projects that don't. I don't have a use case for switching between PPL AF and non-PPL AF while developing within a given project.
Ah, OK. That makes sense. Thanks for clarifying.
I was also somewhat hopeful that you had made a tool that made switching between the two easy.
I have been using an lvlibp of AF by manually adding it to a project. By doing this the AF tooling utilizes the PPL rather than the regular AF in vi.lib to script things.
I store the AF PPL copy in a folder (C:\PPL Builds), my thinking there is that I also keep other PPLs that depend on AF PPL there. It also allows me to make a new AF palette for the PPL, which I find easier than using the project tree to find the right VIs I need. If I stored a copy in each project folder that used it (something I have seen suggested before), I wouldn't be able to make a palette just once. That said, I'm still wondering if this is a good or suboptimal practice, maybe there's an angle I am not seeing.
I'm also curious if anyone has tried replacing the regular AF library in vi.lib with the PPL to remove any chance of accidentally mixing the two in a project. I realize that will break the tooling because it uses some of those VIs as templates, but maybe it's possible to identify which of them are the ones to keep?
There are lots of posts about creating an AF PPL, alot fewer about how to use it during development. I guess I am mostly interested in how others handle their AF PPL in terms of directory structure (during development and where it ends up in the build spec/deployment), how you use it during development (eg. drag n drop VIs from project tree, palette menu, something else?), and any notable consequences that any of this has for your projects.
@DoctorAutomatic wrote:
There are lots of posts about creating an AF PPL, alot fewer about how to use it during development. I guess I am mostly interested in how others handle their AF PPL in terms of directory structure (during development and where it ends up in the build spec/deployment), how you use it during development (eg. drag n drop VIs from project tree, palette menu, something else?), and any notable consequences that any of this has for your projects.
One important thing to keep in mind is the relative path between any other PPLs that you build that depend on your AF PPL. Once you've built one of those, that path relationship is fixed. That's really what drives where we put our other PPLs because when you deploy an EXE, those PPL relative paths still need to be the same.
A folder like "C:\PPL Builds" is fine. We usually end up putting common reuse (across different projects) PPLs in their own repo and using that as a submodule across projects. Then project-specific PPLs go in the project repo so path between the two sets of PPLs are relatively "close".
It's noteworthy that we developed this methodology before using LVSolutionBuilder much though so there are probably ways to leverage that better where you don't end up needing to but PPL binaries in your source code control.
@CaseyM wrote:
@DoctorAutomatic wrote:
There are lots of posts about creating an AF PPL, alot fewer about how to use it during development. I guess I am mostly interested in how others handle their AF PPL in terms of directory structure (during development and where it ends up in the build spec/deployment), how you use it during development (eg. drag n drop VIs from project tree, palette menu, something else?), and any notable consequences that any of this has for your projects.
One important thing to keep in mind is the relative path between any other PPLs that you build that depend on your AF PPL. Once you've built one of those, that path relationship is fixed. That's really what drives where we put our other PPLs because when you deploy an EXE, those PPL relative paths still need to be the same.
A folder like "C:\PPL Builds" is fine. We usually end up putting common reuse (across different projects) PPLs in their own repo and using that as a submodule across projects. Then project-specific PPLs go in the project repo so path between the two sets of PPLs are relatively "close".
It's noteworthy that we developed this methodology before using LVSolutionBuilder much though so there are probably ways to leverage that better where you don't end up needing to but PPL binaries in your source code control.
I'm not somewhere where I can test this for myself, but isn't that relative path link settable in the ppl build spec (the ppl that depends on the AF PPL)? In other words, couldn't you set the destination of the AF PPL in the build spec to the same directory for all dependent PPLs down the road and it works fine?
edit: such that each ppl you build pull AF PPL to the same directory as itself and then in the deployed application all these plugin PPLs rely on a single AF PPL that's in the same directory as all of the plugins?
@CaseyM wrote:
Yeah, that works. Just wanted to be clear that it was something aware of.
Well, I'm back to the drawing board in a sense, after becoming aware of this THIS old thread that I am amazed I only recently became aware of. I recently tried to bring a 32bit project up to 64bit and realized this issue. Seems I should be building things like AF PPL to vi.lib. Is my understanding wrong with regards to the linked thread? Obviously this will only be an issue for anyone who's porting a project that's dependent on a PPL, between targets (in my case 32bit >> x64).
