Beating my foot with a hammer, or using PPLs - which is less painful?

[CoastalMaineBird]

LV2013 SP1, LVRT 2013, Win7

I'm new to PPLs (Packed Project Libraries) and it looks like they might solve a couple of problems for me, but they seem to want to be contrary sometimes.

I've boiled it down to a simple case.  The BROKEN error has come and gone over the past week, I don't understand what brings it on or takes it away.  Today I moved the building of certain PPLs out of the main project and into a separate project, and here it is again.

Here is a 55 -sec JING to show the problem <http://www.screencast.com/t/4NvcjQmVeus>

0:00 I have a LVLIB called JENKINS HASH, I want to make a PPL out of it.  It contains five files (The "64" versions are not used, but similar to the "32" versions, which I DO use).

0:02 I open the HASH 32 PANEL.  It's marked as INLINE SUBROUTINE, but I've tried using it as normal, with no effect.  Note that IT IS NOT BROKEN.

0:04 the Block Diagram shows some arithmetic code, with 3 calsl to a single subVI, and a TYPEDEF (the "hash" outputs).

0:07 the SubVI has nothing but arithmetic code in it. No calls elsewhere.  It is also marked INLINE SUBROUTINE, but changing that has no effect.

0:13 the one TYPEDEF used is a simple U32, formatted a particular way.  It is also in the LVLIB.

0:21 - the BUILD SPEC for the PPL is shown.  The output is called JENKINS HASH.LVLIBP.

0:28 - the only thing in the SOURCE FILE is the single TOP LEVEL LIBRARY, Jenkins Hash.

(I'm using this project for other PPLs too, but they're not germane to this issue).

0:32 - BUILD the thing.  Takes about a second, and you see the new file appear where it's supposed to.

0:39 - Open the PPL (*.lvlibp) and you see the five files in it.

0:41 - Open the VI from the PPL and IT IS BROKEN ?  ? ?

WHY, you might ask.  Well, just click on the broken arrow and LV will tell you, right?

0:45 - Click on the arrow and it tells me "something is missing".

It's not smart enough to tell me WHAT,

If I wanted programming to be painful, I would move to Microsoft C++.

Any ideas?

[CoastalMaineBird]

Hmmm.  The HASH 64 version is NOT broken.

The difference (besides the code itself) is that It uses generic U64 (NOT a typedef) as output indicators.

If I convert the HASH 32 to use generic U32, it succeeds as well.

Why is it originally broken, though?  the TypeDef is right there...

[CoastalMaineBird]

OK, if I change the BUILD SPEC to DISCONNECT TYPE DEFINITIONS (on the ADDITIONAL EXCLUSIONS tab), then it works, even using the TYPEDEF, and set to INLINE SUBROUTINE.

Still, I don't understand this.  I place the indicator from the TypeDef that's in the LVLIB.  I can't place the one from the PPL, because it's not built yet.   So, why doesn't it copy the LVLIB one to the PPL and then use it?

It's as if it's stlil trying to find the original .CTL file, but it's not in a path that the PPL can find.

Is there any sense behind this?

[CoastalMaineBird]

Well, dang.  If I DISCONNECT TYPEDEFS in building the PPL, then place an instance of the VI on a diagram and CREATE CONSTANT from it, the constant is NOT an instance of the TYPEDEF and will not change if the TYPEDEF changes.

Which defeats the whole purpose of a TYPEDEF.

[Taki1999]

I'm trying to find the post on this but I do recall there being some particular nastiness with TypeDefs and PPLs. Basically, the PPL namespacing ends up breaking the TypeDef for anything not living inside the PPL.

EDIT: I think this is what I was remembering.

[CoastalMaineBird]

 the PPL namespacing ends up breaking the TypeDef for anything not living inside the PPL.

Well, in this case, the Typedef and the VI that uses it *-IS-* inside the PPL. 

And it STILL complains that it cannot find it.

[Bob_Schor]

Ouch.  Sounds like the Hammer is the less painful option 

[CoastalMaineBird]

Well, starting from scratch to make a submittable project for Tech Support, and it of course works.

the VI here is an INLINE SUBROUTINE, same as my real code.

The ENUM is a strict TYPEDEF, in the same LVLIB file, same as my real code.

The BUILD SPEC puts it into a different folder from the source, same as my real code.

But I can build and open this one and it's not broken.

Wonder what I'm doing differently?

[CoastalMaineBird]

OK, so I started a brand new BUILD SPEC, plugged in the same info and now it will work when built with the new one, and fail when built with the old one.

FAIL:

GOOD:

Other than the name, no diifference do I see.

FAIL:

GOOD:

FAIL:

GOOD:

FAIL:

GOOD:

FAIL:

GOOD:

FAIL:

GOOD:

FAIL:

GOOD:

[CoastalMaineBird]

I see no difference in those BUILD SPECs, but one of them will always fail, and the other will always succeed.

This means it depends on some bit-rot within the PROJECT, or the Build Spec itself.

Just my favorite thing to have happen - random failures.