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.
