Actors with Multiple Packed Project Libraries

[vishots.com]

This falls in line with how the development process looks for developing VI Packages for your projects or Developing packages (with VIPM) that have dependencies. Replace the term PPL with VIP file. Excellent description.

[SteenSchmidt]

I agree fully Stephen. It's probably a pattern everybody ends up at when they have walked the painful road of exactly what you warn against at the end, namely starting with a coherent code base and trying to make "shared" as well as "unique" components from that.

But stuff in vi.lib will always be common to everything, so the only really safe way around this is to use prefixes for dependencies, right? Or is there a better way in your opinion? Prefixing all dependencies are bound to make huge applications, and trying to decide how to make some sort of "common" component out of what you need from vi.lib just makes you end up with the original problem; a coherent code base you're trying to split up...

/

[LVB]

Thanks for the response, but I don't see how this fixes the problem.

The problem is at step #4 which is a showstopper because (by default) Actor Framework.lvlib gets included within the "Build Chunk 1 as a PPL or DLL".  Thus, everything would have to refer to Chunk1 .lvlibp:Actor Framework.lvlib.  Since Actor Framework.lvlib is in vi.lib, I don't want to place that within Chunk 1.lvlib and thus it would not be assecible to Chunk 2.

I could build Actor Framework.lvlib into a packed library and then have everything reference that (this would be my Build Chunk 1).  I would then have to build a packed library of messages to replace Batch Msg, Reply Msg, Self-Addressed Msg, Time-Delayed Send Message (Actor Messages.lvlibp or Build Chunk 2).  Then I could reference these instead of vi.lib for my other packed libraries.  I haven't acutally tried this yet, but was wondering if there is an easier way to do this?

[AristosQueue (NI)]

LVB wrote:

I could build Actor Framework.lvlib into a packed library and then have everything reference that (this would be my Build Chunk 1).  I would then have to build a packed library of messages to replace Batch Msg, Reply Msg, Self-Addressed Msg, Time-Delayed Send Message (Actor Messages.lvlibp or Build Chunk 2).  Then I could reference these instead of vi.lib for my other packed libraries.  I haven't acutally tried this yet, but was wondering if there is an easier way to do this?

This is exactly correct. No, there is no easier way to do this that I know of. You are creating your own chunk of functionality from a source code base, making that a component assembly.

We could have a standardized PPL of the AF. The thought has crossed my mind that we should be shipping a .lvproj file with the AF that builds such a PPL so that everyone has the option of building the same PPL. But, really, to make that work, we (all of us programmers using the AF) would actually want just *one* distro of the AF, with a single msi version number (or whatever is used on Mac/Linux) so that two programs both using the AF could use the exact same PPL. The work needed to create a shared binary componennt reusable across applications is way larger than the work needed to create a reusable source library. Not something I've ever undertaken.

[AristosQueue (NI)]

SteenSchmidt wrote:

But stuff in vi.lib will always be common to everything, so the only really safe way around this is to use prefixes for dependencies, right? Or is there a better way in your opinion? Prefixing all dependencies are bound to make huge applications, and trying to decide how to make some sort of "common" component out of what you need from vi.lib just makes you end up with the original problem; a coherent code base you're trying to split up...

Not if you actually build a component of just the vi.lib stuff by itself with *only* the parts that  are common to several of your applications so they can all share. Build those first and then build your applications.

Or you take the approach that every VI is part of some component, split vi.lib up into those components (say, one component per subdirectory perhaps) and you compile every component of vi.lib into a separate PPL and then you stop using vi.lib entirely and use only the PPL versions. That would work too. Is that something that NI should be doing with vi.lib? It's crossed my mind. There are lots of pros/cons to the whole discussion. NI developing an installer for every individual PPL so that they can be independently revved? Also something worth considering, though a considerable amount of work. It would allow apps built against the vi.lib PPLs to avoid overwriting each other's components with older versions (assuming newer versions maintain the backward compatibility, usually a requirement for component development).

[LVB]

This is not good.  When building Actor Framework into a packed project library, it generates a broken packed library.  When opening the Actor Framework.lvlibp, it needs to be recompiled every time!  Looking at the Error list says there are 5 VI's that are broken, but none of them have errors!  Ctrl+Shift+click on the broken arrow and the arrows disappear!  However, this happens everytime the Actor Framework packed library is loaded.

To avoid having to modify Actor Framework.lvlib, there are a few choices in the build settings that must be made due to the inlining settings of the message class:

• Debug Build
• Uncheck "Callers adapt at run time to Exported connector pane state"

[AristosQueue (NI)]

Yes. You'll need to edit the VIs to turn off inlining for all VIs that you're building into the PPL. That's part of building a PPL -- no inlines. It makes sense -- you can't pre-compile code and still have the source code available to put into callers.

Backup your vi.lib, make the edits to your vi.lib VIs, build the PPL, then copy your backup over the edited files.

[LVB]

A broken packed library is still generated after disabling all inlining.

[SteenSchmidt]

Stephen, if inlining is a no-go in PPLs how come the builder doesn't either tell you along the build or disable inlining when it encounters it (the latter with an end-of-build report that it did so)? It tastes a bit like when the builder exchanges a poly-VI with the instance, but the instance is private while the poly-VI was public (possible if the poly-VI is in an LVLIB for instance), thus breaking the runtime version of the VI. This issue could be easily spotted by the builder along the way, but no warning or error is passed on to the user - but a broken application awaits you while the build-report told you of a successful build.

I think the builder could be improved quite substantially in these situations.

Best regards,

Steen

[AristosQueue (NI)]

SteenSchmidt wrote:

how come the builder doesn't either tell you along the build or disable inlining when it encounters it (the latter with an end-of-build report that it did so)?

You'd have to ask those who made PPLs and AppBuilder and inlining. When it comes to that sort of thing, I am as much "just a user" as you are. I've just read the error messages and the LV documentation on this topic. I have flagged the developers invovled that this is an issue.