Building an installer for LVOOP based plugins

[jlokanis]

That seems like a weird solution.  The EXE would just be an empty shell and all my code would exist in PPLs.  Which from what I have seen so far are a bit of a nightmare to maintain.  Maybe next time I design an entirely new app from the ground up I could try using PPLs from the beginning.  Refactoring an existing project into PPLs is just not practical from what I have see and read.

I think I will stick with 'tradtional' design for now.  I don't think I want to touch PPLs with a 10 foot PPole.

[AristosQueue (NI)]

> The EXE would just be an empty shell and all my code would exist in PPLs.

Exactly.

And it actually shouldn't be a nightmare to maintain... I've seen this actually done at a couple of companies already and it dramatically simplifies a lot of things. For one thing, you can actually test your built PPL code in the IDE, which you cannot do with the EXE.

> Refactoring an existing project into PPLs is just not practical from what I have see and read.

Refactoring, no. Wholesale picking up and moving the whole kit and kaboodle into a library? That's often straightforward. I suggest it is worth exploring at the very least given everything else you're talking about.

[jlokanis]

Still not convinced.  Next time I am in Austin, I'll show you this project and see if you still think PPLs are doable.

[AristosQueue (NI)]

Believe me -- I'm not trying to convince you to do it... not all projects are amenable. I just wanted you to evaluate it. As strategies go, it's closer to the ideal than anything else I've seen for these larger LV systems. But if you have evaluated it and decided not to go that route, well, that's why they call you an architect -- you know the tradeoffs for your system better than anyone else! 🙂

[jlokanis]

I will look into it more.  I was warned off PPLs a few years back because of some issues.  I later read some posts about how to use it for plugins but then realized that I would have had to build my entire architecture (that the plugins share with the main app) into PPLs first before it would work.  Then I have a large amount of supporting classes that are shared by several applications as well as a lot of miscelaneous reuse code that does not live in a class or library.  It seems like it would be hard to get it all into PPLs and get them linking to each other correctly.  Then if I need to edit something in the IDE, it means a recompile which seems like it would slow down my debug cycle.

But, I am not saying never.  I will need to learn more aobut these and maybe do some experiments with them in the future.

[bsvare]

I've designed two significantly large systems (And some people from R&D have seen it). In the most recent, there's about 10 different EXEs for various views I want to give the person(s). I'm over 100 PPLs, many of which call other PPLs, about 500's of external DLLs. It's also initregrated in TestStand,

I've never had an issue using PPLs in creating or running this system. It's possible what you read was first version of LabVIEW to create them. It has come a long way since. It's really worth understanding PPLs and how beneficial they can be. It might require you to change slightly on how you design, but that will help your architecture in the long run.

I Highly recommend looking into PPLs more. It's made my project a lot simplier to write and debug.

[AristosQueue (NI)]

I'll claim that all of what bsvare said is especially true as of LV 2015 where PPLs got some very intense love and care.

[tyk007]

Can you provide more detail on the 2015 improvements?

[AristosQueue (NI)]

See 2015 upgrade notes. Should all be in there.

[tyk007]

Do you mean this? http://www.ni.com/pdf/manuals/371780l.pdf

I found this through http://digital.ni.com/express.nsf/bycode/upnote15

There's very little in there regarding PPLs. Can you shed any more light?