Modifying build spec programatically

[Worle]

I am trying to modify some build specs programmatically in order to make some CI server tooling.

I am trying to specify the destination directory and the version number.

The attached VI works on one project, but not on others. I don't seem to be able to work out why. 

On the projects it doesn't work on, if I read the tags back programmatically they are correct. But if I open the build spec in LabVIEW they are still the original values. 

I am guessing that LabVIEW is caching the buildspec/rebuilding it somewhere. (Clearing the compiled object cache and application builder cache in this VI doesn't help)

Does anyone have any suggestions?

[Bob_Schor]

This sounds like a problem I raised in the Forums a while ago about Pre-Build actions.  I was using Pre-Build actions, assuming that when I said "Build", it would carry out any commands that I placed in the "Pre-Build Action", and would then start the Build process.

I was (and still am) using Subversion as my Version Control system, and wanted the Program Version, consisting of 4 numbers separated by dots, to have the last element be the current Subversion "version".  So I made my Pre-build Action query Subversion for its "Version" number, change the value buried somewhere in the Project file (using the fairly-new Hidden Gems in vi.lib to get it for me), modified it to the Subversion number, then did my build.  But it didn't work -- as some LabVIEW developer explained to me, parts of the Build Spec were cached before the Pre-Build Actions (and he wasn't bothered by the fact that "Pre-Build" means "before the Build").  My original "solution" was to build twice, once to get the Subversion "version" into the Project, the second time to have it there to be cached, and then be usable.  I was not happy.

Bob Schor  

[Andrey_Dmitriev]

---

@Bob_Schor wrote:

This sounds like a problem I raised in the Forums a while ago about Pre-Build actions.  I was using Pre-Build actions, assuming that when I said "Build", it would carry out any commands that I placed in the "Pre-Build Action", and would then start the Build process.

I was (and still am) using Subversion as my Version Control system, and wanted the Program Version, consisting of 4 numbers separated by dots, to have the last element be the current Subversion "version".  So I made my Pre-build Action query Subversion for its "Version" number, change the value buried somewhere in the Project file (using the fairly-new Hidden Gems in vi.lib to get it for me), modified it to the Subversion number, then did my build.  But it didn't work -- as some LabVIEW developer explained to me, parts of the Build Spec were cached before the Pre-Build Actions (and he wasn't bothered by the fact that "Pre-Build" means "before the Build")....

---

We've got almost the same trouble in the past. But in our special case we have PlugIn architecture, where we have one project for one plugin and in each project (with own build spec) we have lvlib. So, it was "solved" by using library's version instead of build version, then this version was incremented as we wanted in Pre-Build Action (in additional we generating build log from here, as result on the server we have also a history of the builds). It works so far, but wasn't easy to achieve, because lot of empirical "workarounds" was added to get these things done.

[raphschru · Accepted solution]

Hi Niatross,

If you want to set absolute destination paths, you must set the path types accordingly:

Also, be sure to use method "Project.Save" on the project reference from which originates the build spec and then you can build using the "Build" function from the application builder.

Regards,

Raphaël.

[Worle]

---

@raphschru wrote:

Hi Niatross,

If you want to set absolute destination paths, you must set the path types accordingly:

Also, be sure to use method "Project.Save" on the project reference from which originates the build spec and then you can build using the "Build" function from the application builder.

Regards,

Raphaël.

---

Setting the path types fixed the problem. Out of interest how did you discover this? I have struggled to find documentation on this area of LabVIEW.

[raphschru]

This is indeed not documented. I discovered this while creating a tool that could build for multiple LV versions at the same time. This was a lot of trial and error by modifying the build spec through the project, then looking at the result in the XML, but I finally got it working.

More infos on a comment about relative build destination paths:

https://forums.ni.com/t5/LabVIEW/Relative-Build-Spec-Path/m-p/4362108#M1281205

Regards,

Raphaël.