Relative Build Spec Path?

[_carl]

23Q1. I've got a build spec, on a multi-developer project. We're using source control and may have our root folder set up to different locations than each other (because we should be able to).

However...I can not figure out how to get the destination directory of my PPL build spec to be relative:

LabVIEW is maintaining this as an absolute path if I look at the project XML. If I modify the XML to use relative paths, it fails to read this and then defaults to the default destination directory. Is there any way to make this path relative?

(The best I can come up with at the moment is to write something to programmatically updates all build specs, and then ask developers to run this on their machines...but this is a terrible implementation because it a) adds an unnecessary step that will get missed and b) means we're all making localized file changes making source control more painful.)

[Kyle97330]

What about using both the "before build" and "after build" functions in the Pre/Post Build Actions category to change the build path to one specific to the machine it's on, then changing it back to the original one afterwards?

If it's in there then it's an automatic step when building and can't be missed, and reverting it back to the original one means the next time you commit it won't show up as a change.

[Andrey_Dmitriev]

---

@_carl wrote:

23Q1. I've got a build spec, on a multi-developer project. We're using source control and may have our root folder set up to different locations than each other (because we should be able to).

However...I can not figure out how to get the destination directory of my PPL build spec to be relative:

---

It is relative already, as long as build spec is located within same root folder as project. It looks absolute, but actually is relative.

For example, I'll create my simple project in "C:\Users\Andrey\Desktop\MyProject\src" folder. Then if I will create build spec for PPL it will be placed by default in "C:\Users\Andrey\Desktop\MyProject\builds\Untitled Project 1\My Packed Library". Now If I will rename "MyProject" to "MyNewProject", then the path will be changed accordingly. If I'll place project in subfolder, then buld spec will be created relative to this. Also, if I will move this project to other drive, then build spec will follow new location.

But of course, if I will change it manually to something like "C:\builds", then LabVIEW will be unable to resolve this path when whole project is moved relative to this location, and as result this will keep this entry (is also useful for automated builds).

This is true not only for PPLs, but also for any other spec like Application, source code distribution, etc.

[AlexElb · Accepted solution]

The destination directory of a build specification can only be defined by the user as an absolute path. However, internally it can be handled as a relative path in the project file. Under certain circumstances, the property <Property Name=“Bld_localDestDirType” Type=“Str”>relativeToCommon</Property> is added to the .lvproj file. In that case, when building the build specification, the directory will be created at the same relative position to the project file.

• relative path: destination directoy is not more than one level above the project file, at the same level or under
• absolute path: destination directory is more than one level above the project file

With this information, we were able to solve the problem.

However, there is also this new tool, which you could give a try:

https://www.vipm.io/package/illuminatedg_lib_ig_relative_build_paths/

[_carl]

---

---

It is relative already, as long as build spec is located within same root folder as project.

---

That's a big caveat: my required build location is not immediately in the root project folder -- it's three directories up requiring a path along the lines of "../../../builds/project folder/my ppl.lvlibp".  LabVIEW does not create paths like this to be relative, and if I edit the XML to provide a relative path in the project XML, it does not load properly. (I tested a number of combinations as a sanity check, and I'm pretty sure I entered valid relative paths -- but perhaps there's a syntax requirement I overlooked...?)

I'm guessing that the answer is that LabVIEW simply won't (natively) support relative build paths if they're not directly in the project folder?  It's interesting that other relative paths (like dependencies) works just find in the XML -- I don't see why it wouldn't be supported here.

@AlexElb:

---

relative path: destination directoy is not more than one level above the project file, at the same level or under

---

You seem to have encountered the same problem -- I don't imagine there's an XML property that can be added to support relative paths for files that are more than one level above the project file?

[Andrey_Dmitriev]

---

@_carl wrote:

---

---

It is relative already, as long as build spec is located within same root folder as project.

---

That's a big caveat: my required build location is not immediately in the root project folder -- it's three directories up requiring a path along the lines of "../../../builds/project folder/my ppl.lvlibp".  LabVIEW does not create paths like this to be relative...

---

Well, got this.

Technically this dialog, where you defining the path is just VI which is located in <LabVIEW>\resource\Framework\Providers\Builds\AppBuilder\AB_UI_Page_Info.vi. Seems to be not password protected. At least you can take a look inside and check what happened under the hood, and may be modify as needed (it is probably not a good idea to modify core LabVIEW files, but at least interesting experiment).

[raphschru]

Hi _carl,

Pretty much everything has already been said by the previous commenters, but here is a summary plus some additional infos:

1. The destination directory is always displayed as absolute in the build specification properties, however there are cases where it is internally saved as a relative path:

a) If your destination directory is inside (or equal to) the project directory, "Bld_localDestDir" will be relative to the project path:

b) Else, if your destination directory is inside (or equal to) the immediate parent directory, "Bld_localDestDir" will be relative to the project path stripped once:

c) Else, "Bld_localDestDir" will be stored as an absolute path:

Note: here "Bld_localDestDirType" is missing, making the path absolute by default.

2. You cannot programmatically edit a build specification (by accessing the project item refnum) from the pre-build action of this same build specification, obviously because the build properties are already loaded and fixed for the current build.

If you really want to programmatically edit a build specification, you would have to create a build script instead of clicking "Build" manually. It would first edit the build spec as desired, then make the build by calling the Application Builder VIs, then restore the build spec to its initial state. This solution is the most general but also the hardest to develop and test.

3. Another alternative (preferred) is to build to a relative directory (in the project directory or one level higher), and then in a post-build action, copy the built files where you need them to be.

Regards,

Raphaël.

[paul_cardinale]

See the VIs I shared here:

https://forums.ni.com/t5/LabVIEW/Call-an-installer-or-build-vi-from-another-vi/m-p/4360878#M1280681

[_carl]

Thanks for the feedback everyone!

Sounds like this isn't natively possible, and that the best solution is just to build to a location in the project folder, and then to run a post-build action to move all the files.

That said, I feel like relative paths should just be supported here (I've encountered this before), rather than having to jump through these hoops...and have posted this request on the idea exchange.

[paul_cardinale]

---

@_carl wrote:

Thanks for the feedback everyone!

Sounds like this isn't natively possible, and that the best solution is just to build to a location in the project folder, and then to run a post-build action to move all the files.

That said, I feel like relative paths should just be supported here (I've encountered this before), rather than having to jump through these hoops...and have posted this request on the idea exchange.

---

Did you not check out the link I posted?