LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

PPL / LVLIBP Build Spec Naming Conventions?

Hi,

 

I happend to stumble across a behaviour I find kinda strange (if not bug-worthy)

 

What I tried to do: create two different lvlibp (debug / release) versions

What I did:

Create two build scripts

1.) Debug Version

Build Spec Name: Debug_MyLib.lvlibp

Target filename: MyLib.lvlibp

Destination Directory: <build dir>\Debug\

 

2.) Release Version

Build Spec Name: Release_MyLib.lvlibp

Target filename: MyLib.lvlibp

Destination Directory: <build dir>\Release\

 

Both scripts build sucessfully (in terms of not showing erors during build). No, here comes the fun part: closing the project and opening either one of those "successful" builds, the welcome screen disappears, five seconds or so later re-appearing not having opened the library. Using this build in another project BTW will give you hell in terms of nerver ending project load times and broken object hierarchies... found that out the hard way Smiley Sad

 

Thank God for having used SCC to roll back to the last working version featuring a single build script:

 

Build Spec Name: MyLib.lvlibp

Target filename: MyLib.lvlibp

Destination Directory: <build dir>\MyLib\

 

Everything was working fine again.

Not wanting to let go, I started investigating / experimenting:

 

Finding 1.) Leaving out the lvlibp extension on Build Spec Name will cause errors

 

Build Sepc Name: Debug_MyLib

Target filename: MyLib.lvlibp

Destination Directory: <build dir>\Debug\

 

Error 1059 occurred at AB_Source_Library.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi

 

Finding 2.) Leaving out the lvlibp extension on Build Spec Name and have similar names will cause errors as well

 

Build Sepc Name: MyLib

Target filename: MyLib.lvlibp

Destination Directory: <build dir>\Debug\

 

Error 1059 occurred at AB_Source_Library.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi

 

So, to me it looks like LabVIEW would require Build Spec and Target Filename to be the same. I've done a lot of PPLs in the past, but so far, the names have always been the same.

 

Leaves me wondering if this expected behaviour or rather a bug?

Using 15.0.1f1

 

Cheers 

Oli

0 Kudos
Message 1 of 16
(3,879 Views)

Oli,

 

i am sorry, but i have only 2016 installed. However, when trying to reproduce your situation with a single increment VI inside a lvlib, i was not able to reproduce the error. In fact, everything worked fine.

Besides, when selecting a new Packed Library build spec, by default the name of the build and the PPL name are different:

PPL Build Spec.PNG

Also note that the build spec name does not append .lvlibp.

I am not aware that there were major changes regarding build specs between 2015 and 2016.

 

Can you verify if such a simple setup (one lvlib with only one 'generic' VI) works for you?

If it does, what are major differences to your project (e.g. other dependencies like DLLs)? Do you use Pre/Post Build Actions?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 16
(3,803 Views)

Hi Norbert,

it seems to work correctly with simple LVLIBs

 

The complex LVLIB in question is composed of several sub-LVLIBs (not my best piece of work, but I am sure I had a reason to commit a crime like this Smiley Indifferent)

Furthermore I intended to use a Pre-Build VI to set Conditional Disable Symbols.

No Post-Build VIs.

 

Cheers

Oli

 

 

0 Kudos
Message 3 of 16
(3,796 Views)

@Oli_Wachno wrote:
[...] is composed of several sub-LVLIBs [...]

 


I hope there are no cyclic dependencies!

Are all these lvlibs going to build into the single lvlibp or do you build them to individual lvlibps?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 16
(3,794 Views)

Hi Norbert,

 

of course not Smiley Very Happy This very LVLIB is working correctly in 2013.

There are several sublibs, but all on the same hierarchy level. The "Toplevel" lib which is to be built contains those.

Oli

0 Kudos
Message 5 of 16
(3,791 Views)

Error 1059 is a generic error "unexpected file type". Are there non-LV files in the lvlibs?

 

What is up with LV 2013? Do you tell that you can build that build spec in LV 2013 without these errors?

 

Does the error popup right when starting the build or does it happen once some files have been copied?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 6 of 16
(3,789 Views)

There are only LabVIEW type files in the LIBs. Luckily, the error occurs right at the start.

 

The 2013 build runs without problems, the only difference regarding the build script is that I have duplicated it and have created a debug and a release version.

 

One further detail I haven't metioned yet:

If I successfully build a broken LVLIBP (irony intended) and try to open it while the project is loaded, I get an error message stating some VI could not be loaded. The VI not found is prefixed using the buildscript name... but I did not really pay intention to it....

0 Kudos
Message 7 of 16
(3,786 Views)

Can you attach the project file?


Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 8 of 16
(3,783 Views)

Sure thing

 

It contains three build scripts: the ones marked donotuse are those making trouble

 

 

 

 

0 Kudos
Message 9 of 16
(3,780 Views)

Reading the build scripts in Editor, i can see that you have stated two sources:

/My Computer/PanelClasses.lvlib/Abstract SubPanel Children/Generic_UI_Controller.lvlib

/My Computer/PanelClasses.lvlib

 

As you can see, the first lvlib is a sublibrary of the other one... if not, i would recommend a different folder setup.

I am not sure what happens if you define a sublibrary as an additional item when already including the parent library....

 

As this configuration is also in the working build script, i am not sure how far this really affects the issue. However, i recommend to verify this.

 

Is it also possible for you to break the project down to a couple of files where the issue occurs?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 10 of 16
(3,775 Views)