10-13-2016 03:22 AM
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
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
10-20-2016 02:51 AM
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:
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
10-20-2016 08:38 AM
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 )
Furthermore I intended to use a Pre-Build VI to set Conditional Disable Symbols.
No Post-Build VIs.
Cheers
Oli
10-20-2016 08:45 AM
@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
10-20-2016 08:51 AM
Hi Norbert,
of course not 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
10-20-2016 08:58 AM
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
10-20-2016 09:13 AM
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....
10-20-2016 09:14 AM
Can you attach the project file?
Norbert
10-20-2016 09:17 AM
Sure thing
It contains three build scripts: the ones marked donotuse are those making trouble
10-20-2016 09:33 AM
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