Relative Build Spec Path?

[_carl]

---

@paul_cardinale wrote:

---

---

Did you not check out the link I posted?

---

That has the downside of only working from an automated build tool.  I'd still like to be able to manually run the build spec from a project.

[paul_a_cardinale]

---

@_carl wrote:

---

@paul_cardinale wrote:

---

---

Did you not check out the link I posted?

---

That has the downside of only working from an automated build tool.  I'd still like to be able to manually run the build spec from a project.

---

Which is possible to do.  I'm sure I  have something that does that.  Maybe later today I'll start digging.

[_carl]

---

@paul_a_cardinale wrote:

Which is possible to do.  I'm sure I  have something that does that.  Maybe later today I'll start digging.

---

I don't believe it is. (at least without some trickery)

What I'm looking for is:

- The ability to provide a relative path in the build spec, but one that is multiple directories up from the project.  I'm ok with modifying XML. I'm also ok if this can be done once, through an API.

- I need the file to remain unchanged but functional when deployed to different user's machines.

- I want to be able to run the build spec manually by right-clicking on it in the project.

To the best of my knowledge, and per feedback already received here, this does not seem to be possible without adding an extra overhead, such as a post-build action that moves files. I'd love to be proved wrong though.

[AlexElb]

May I ask why you are trying to achieve this? It may be, that the problem you are trying to solve, doesn't require the way you are trying to go. Can you change your requirements by redefining your goal?

Why do you need a relative path multiple directories up from the project?

For example:

If all developers have the PPLs at a common absolute path like c:\myPPLs, you wouldn't run into this problem.

If all developers have the PPLs inside the repo, where lvproj supports a relative path, you wouldn't run into this problem.

[Andrey_Dmitriev]

---

@AlexElb wrote:

May I ask why you are trying to achieve this? It may be, that the problem you are trying to solve, doesn't require the way you are trying to go. Can you change your requirements by redefining your goal?

Why do you need a relative path multiple directories up from the project?

---

I' m not the author, but I can understand the needs to have relative path, which goes up outside of the project folder — this might be useful for multiple projects, building PPLs in monorepository, but this one is still relative and not absolute. In general depends from source code's organization.

In additional, just from usability point of view — even if used inside of the project, this relative path appeared to be absolute.

For example, if my sources located in D:\MyProject\src and build is located in D:\MyProject\build, then I also prefer to have "..\build" here instead of "D:\MyProject\build", because in fact this is relative path appeared as absolute, but if I will move project to another location, then it gets changed automatically, and for me this is a very strange "design" decision. I also prefer to have this like in MS Visual Studio. So, if I enter truly absolute path, also within the project folder, this should stay absolute and should be not changed under any circumstances, and if relative, then stays relative, that is.

In ideal case I would like to see  both - my entered relative path and somewhere below this field - how it currently resolved to the final target destination:

[_carl]

---

@AlexElb wrote:

May I ask why you are trying to achieve this? It may be, that the problem you are trying to solve, doesn't require the way you are trying to go. Can you change your requirements by redefining your goal?

Why do you need a relative path multiple directories up from the project?

For example:

If all developers have the PPLs at a common absolute path like c:\myPPLs, you wouldn't run into this problem.

If all developers have the PPLs inside the repo, where lvproj supports a relative path, you wouldn't run into this problem.

---

The use case: multiple PPLs, relying on other PPLs, in the same repo.

• Since PPLs are in effect source (and needed by other PPLs), they can't be at an absolute path.
• Desire to have final PPLs organized in a clean folder structure for deployment. (In the simplest case: a "Plugins" for for plugins, and a "Core PPLs" for all other stuff.) Other PPL limitations basically mean building these in the correct relative location initially.
• Having PPL source code be dependent on PPLs, not PPL's source code, which requires a separate project for each build spec. (Not to derail this thread, but when you have 100s of classes with the same parent definition, LabVIEW can take half an hour+ to add a single piece of class data...negating any value in linking to source rather than compiled code.)
• Desire to not have source code sitting in the folder structure as PPLs -- because that's a complete mess in this situation.

Regardless of the merits of my specific use case though, there's really no reason you shouldn't be able to have a relative path that's up a few directories.  There are plenty of reasons users may want this, usually just for better organization of build and source code.

[AlexElb]

Please don't get me wrong - I would also love to see that LabVIEW supports relative paths here! I've run into this problem a lot of times.

Knowing when LV allows us to use a relative path, made it possible to solve my problems by arranging the files in the repo.

repo_root/
├─ PPLs/
│ ├─ PPL1.lvlibp
│ ├─ PPL2.lvlibp
├─ Source/
│ ├─ Modules/
│ ├─ Libraries/
│ ├─ myProj.lvproj

• I'm using a flat hierarchy in the PPLs folder, because I don't have hundreds of PPLs yet.
• The repo for PPL2 which depends on PPL1 has the same structure.
• The Source of PPL2 lives in the Source folder and the build destination of PPL2 is the PPLs/ folder.PPLs get build in the correct relative position to each other inside the repo. You can move the repo around, build executables etc.

I've just tried to create a more nested folder structure inside the PPL folder. The . lvproj shows

<Property Name="Bld_localDestDir" Type="Path">../PPL/Core/even/More/Nested</Property>
<Property Name="Bld_localDestDirType" Type="Str">relativeToCommon</Property>

I can load the .lvlibp from /PPL/Core/even/More/Nested, and it loads its dependent PPL from /PPL without problems.

For me, it seems your use case can be solved. Are you sure you tried moving your .lvproj "high enough"? When defining your destination directory, keep it max. one level above the .lvproj file in your folder structure.It is possible to go up one level and then go down again.

[_carl]

---

@AlexElb wrote:

Please don't get me wrong - I would also love to see that LabVIEW supports relative paths here! I've run into this problem a lot of times.

Knowing when LV allows us to use a relative path, made it possible to solve my problems by arranging the files in the repo.

repo_root/
├─ PPLs/
│ ├─ PPL1.lvlibp
│ ├─ PPL2.lvlibp
├─ Source/
│ ├─ Modules/
│ ├─ Libraries/
│ ├─ myProj.lvproj

• I'm using a flat hierarchy in the PPLs folder, because I don't have hundreds of PPLs yet.
• The repo for PPL2 which depends on PPL1 has the same structure.
• The Source of PPL2 lives in the Source folder and the build destination of PPL2 is the PPLs/ folder.PPLs get build in the correct relative position to each other inside the repo. You can move the repo around, build executables etc.

I've just tried to create a more nested folder structure inside the PPL folder. The . lvproj shows

<Property Name="Bld_localDestDir" Type="Path">../PPL/Core/even/More/Nested</Property>
<Property Name="Bld_localDestDirType" Type="Str">relativeToCommon</Property>

I can load the .lvlibp from /PPL/Core/even/More/Nested, and it loads its dependent PPL from /PPL without problems.

For me, it seems your use case can be solved. Are you sure you tried moving your .lvproj "high enough"? When defining your destination directory, keep it max. one level above the .lvproj file in your folder structure.It is possible to go up one level and then go down again.

---

Ahh...the difference here is that you're able to get away with one project. I'm tied to having one project per PPL (since each of my projects only has dependencies on compiled PPLs and its specific source code), which means that those projects really do belong in the same folder as their module's source code.

[AlexElb]

---

@_carl wrote:

---

Ahh...the difference here is that you're able to get away with one project. I'm tied to having one project per PPL (since each of my projects only has dependencies on compiled PPLs and its specific source code), which means that those projects really do belong in the same folder as their module's source code.

---

We are getting closer 😀 However, I'm also having one project per PPL and one repository per project.

Repo1: PPL1 has no dependency, just VIs and a lvproj in repo1\Source. The PPL gets build into repo1\PPLs.

Repo2: PPL2 depends on PPL1, thus I've copied the built PPL from repo1\PPLs into the repo2\PPLs. Again, Source for PPL2 and its lvproj live in the repo2\Source; PPL2 is being build into next to PPL1 at repo2\PPLs

Do you also have a repository per project? Manually copying the PPLs into the repos of course is ... manual work. But that way I can update a PPL for projectA without having a side effect on projectB, what I definitely want to avoid.

Maybe you want to draw your folder structure as well?

[paul_cardinale]

I tried a lot of things.  This is the closest I could get.

There are 2 buildspecs.  The first one fixes up the destination path of the second one (which is the real build).

The true relative destination path is specified in the description of the 2nd buildspec.

Unfortunately you can't use Build All (because at the start it caches all the settings of all buildspecs, thus preventing any changes).