LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Scratching my eyeballs with a nail, or using PPLs - which is less painful?

LV 2013 - More PPL madness.

 

I'm building an addon system, where the user can make addon pieces that are recongnizeable by my host piece and have them work together.

 

I am moving some of my code into PPLs (Packed Project Libraries) in order to make that code available both to the main host and to these addons.

 

I have a control called "Units".  It's an ENUM with values like "degC", "degF", "degR", "N-M", "Ft-Lb", etc., etc.  Since it's used everywhere and might be useful in the addons, I moved that control and the code that goes with it (units conversion, etc) into a PPL of its own.

 

Fine.

 

I have another PPL that manages channel selectors.  It sorts the list of channels alphabetically or by hardware type, or by cal date, and manages the pop-up menu, and manages a units indicator that is associated.  (If you switch to watching a temperature channel, for example, it switches the associated indicator to "degC".

 

So, it uses the UNITS indicator from the first PPL.

 

I discovered an error in my structure - the ChanSel manager uses the UNITS indicator from my Units LVLIB (the original), not the one from the units PPL. As a result, there are lots of coercion dots when I use the ChanSel manager, because the units I feed it from outside are the copy from the PPL, but it uses the original LVLIB copy.

 

So, I changed the ChanSel manager to use the UNITS control from the PPL.

 

But now, it complains when I BUILD the ChanSel manager: "Cannot Build the application because the folllowing source files are in the destination directory.  You must build the application to a different directory from the source files", and it refers to the UNITS ppl.

 

I understand that it uses the UNITS PPL as a source file, but what is the problem with having a source file in the same folder as a dest file?

 

And then it gets even more maddening: if I put all the PPLs (I have about 15 now) in individual folders, then the build process will COPY the UNITS PPL into the same folder that it builds the ChanSel Manager PPL in!  In other words, it does itself exactly what it complained about me doing.

 

And, on top of that, when it's time to open the project that USES them, it now will complain that there are TWO copies of the UNITS ppl and it doesn't know which one to use where.

 

Is there any sense behind this?  If so, shine a light on it, please.

 

Do I have to make a post- build action to put them where I want them?, or is there a Don't-be-so-dang-stoopid option I can turn on?

 

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 5
(3,090 Views)

SO, to work around this silliness, I changed the Build Spec to put the PPL I'm building into a folder all its own, and made a POST BUILD VI which moves it where I want it, and deletes the folder and associated detritus.

 

Still, I don't understand why this is necessary.

 

Post Build.PNG

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 2 of 5
(3,057 Views)

CoastalMaineBird wrote: 

I understand that it uses the UNITS PPL as a source file, but what is the problem with having a source file in the same folder as a dest file?


While I haven't run into this situation specifically, I believe this is in place to prevent you from accidentally overwriting a source file with a file with the same name in the build. For example, let's say you have a VI set to always include in your build specification (because you want to call it dynamically) and you set the location for it in the build to match the source location, and you also have the remove block diagram build option set (this is the default). Would you want your source code overwritten by the compiled version? It's easier for LabVIEW to enforce a rule that the build directory be separate from the source, than to try to figure out for which file types it would be safe for source and build to mix. Build systems in other languages likewise encourage a separate build directory, although I don't know how many enforce it.

0 Kudos
Message 3 of 5
(3,031 Views)

Duplicate post.

 

Spoiler
😄
Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 4 of 5
(3,016 Views)

Would you want your source code overwritten by the compiled version?

 

Of course not, but when the destination has a completely different name from the target, that's not even remotely possible.

 

I suppose that the AppBuilder thinking is this:

1... I'm building ChanSel Manager.lvlibp from ChanSel Manager.lvlib.

2... That ChanSel Manager.lvlib needs something in UNITS.lvlibp.

3... Because of #2, I need to COPY the UNITS.lvlibp from where it is to my  build destination.

4... Because of #3, I'm trying to COPY a file from where it is to where it is.

 

Rather than recognize that it's already there, it complains.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 5 of 5
(3,009 Views)