Application build destination directory should not require absolute paths

[MGiacomet]

It makes no sense (from a Software Engineering and Process standpoint) to force (and store) an absolute path for a build destination directory, in the project. What if a group is sharing a project but each developer prefers to have their files located in a different folder?!!

I recommend NI consider replacing the line of code in LabView that is checking for the presence of an absolute path for the build folder with on that does: "If user entered an absolute path, use it; otherwise, prepend the current project location to whatever (relative) path the user entered before building."

[Bob_Preis]

The destination paths, though absolute in the UI, are kept relative to the project if they start off relative to the project. So, if you move the project around and open the build spec, you should see the paths updated, and still relative to the (new) project path.

[MGiacomet]

Furthermore...

If you right-click on the build specification, select Properties and look at the Information category: There you can select a "Destination directory", that must be absolute or a dialog box pops up.

Conversely, if you look at the Destinations category, there is also a destination path which allows one to enter a relative path (no dialog box pops up).

BUT... a relative path put there has no effect. In fact has an unexpected effect, which is LabView creating a folder called "builds" one level below where the project is located.

Clearly it is a bug (not to mention the inconsistency above).

[MGiacomet]

GregR,

Since you used the word "We", I must assume you work at NI. Excellent!!! Below are step-by-step instructions on how to reproduce the issue. Please try them.

1. Create a folder C:\Project1

2. Create a folder C:\Project1\build

2. Start LabView

3. Create an empty project

4. Save it in C:\Project1

5. Create a new VI

6. Drop some element in the VI

7. Save it in C:\Project1

8. Create a build (.exe) specification and point the build to C:\Project1\build

9. Build it; you'll find the executable in C:\Project1\build

10. Save and close everything (including LabView)

11. Create a folder C:\Project2

12. Create a folder C:\Project2\build

13. Move everything (except the build folder) from C:\Project1 onto C:\Project2

14. Start LabView

15. Open the project now located in C:\Project2

16. Build it

17. Notice that the dialog box at the end of the build says "You can locate the results in C:\Project1\build", not in "C:\Project2\build", if it were using relative paths. The absolute path IS retained.

Can you post a project that does what you say it does?

Thanks.

[AristosQueue (NI)]

MGiacomet: If you look at user names at the top of each post, anyone who works for NI will have their name in blue instead of gray.

I can confirm what you're seeing -- and I can confirm that the paths ARE relative paths. How can that be?

Here's what saves in the .lvproj file:

<Property Name="Bld_localDestDir" Type="Path">../Project1/build</Property>

The paths is relative to the directory above the project file, not to the project file itself.

I don't work on AppBuilder so I'm only commenting on this as a user, not as a developer... If you notice, when you create a new Build Specification, the initial path that LV fills in is always a directory that is a sibling to the directory that contains your project, not a directory under the project. I've never liked that, and I pretty much alway change that initial path. But it seems clear that LV is saving a path under the belief that you are always picking a path that is a sibling to the project and that this is desirable.

What it means in practice is that all of your projects would end up in the same directory if all you did was copy the project directory. You would need to have a root directory that had in one side the project and in the other side the build and then copy that root directory to make the relative paths have any meaning.

I'm going to go out on a limb here and say this is probably intended behavior, but I think it's pretty hard to use and I'd support changing it. I'll add my kudos to this idea.

[DerrickB]

Necropost!

I'm still running into this issue today. Here's the offending line in the project file:

<Property Name="Destination[0].path" Type="Path">/C/LabVIEW/build/ppl/ProcessValueManager.lvlibp</Property>

Just look at that juicy absolute path! I've recently royally screwed myself after a chain of mistakes resulted in me overwriting incorrect files and setting myself back about 2 weeks. I was previously working on a machine with multiple versions of labview installed (2011, 2013, 2014). Basically I'll never do that again. Ever.

My current process now uses GIT and when cloning to a new machine it still has the absolute paths of the previous location I commited from.

Please allow relative pathing.

[AristosQueue (NI)]

DerrickB: Is your project on a different drive? The only way that I get an absolute path stored there is when my project is on one drive and my build site is on another drive.

As we said above -- the paths are saved relative whenever possible. Can you identify what you did to make it an absolute path?

[DerrickB]

These were projects that I was upgrading from 2011 to 2014. They were previously just stored in lvlibs without build specs. I resaved the projects/libs for 2014 and added build specs to create ppls and begin replacing the bare references to the lvlibs to the compiled ppls.

All of this work has been done on computers that only have a single hard drive. When updating to 2014 they were moved from various folders in /c/labview/ to /c/labview 2014/, saved, and then the build specs were added (all ppls to /c/labview 2014/build/ppl). Some of the libraries I had started to move to the ppl model before upgrading to 2014 but the snippet above was from a library following this method.

I just now noticed the absolute paths when cloning from git and moving back to a /c/labview/ location since there will not be multiple labview versions installed in this VM.

I did create a new project with a ppl build spec and it did in fact save it with a relative path so I'm not sure at what point the absolute paths started showing up.

Ahh. I just created a new build spec to go to a different folder within the C drive and it's an absolute path. instead of putting ../../labview 2011/build/ppl it's putting the fully qualified /c/labview 2011/build/ppl. Is it resorting to an absolute path whenever it hits the top level of a drive even if it's not changing drives?

[AristosQueue (NI)]

DerrickB: Open your project file in a text editor and change the path to be a relative path... I think that'll work. It's not my area of expertise, but I think everything works fine.

[MGiacomet]

AristosQueue wrote: "As we said above -- the paths are saved relative whenever possible."

AristosQueue, the key is at the end of your own sentece: "whenever possible" Why??? How about using the KISS (Keep it Simple S...) method:

-If the user enters an absolute path, use it!

-If the user enters a relative path, use it!

Simply remove the code that tries to do the "whenever possible".  It will be less code for NI to maintain (maintain? well...) and does what the users need. How easier can it be?

[DerrickB]

Coming back again. Still having this issue in 2017.

Project sources look like:

C

-LabVIEW

--build

---bin

---ppl

---plugins

---config

--ClientA

---ProjectA

----ProjectA.lvproj

ProjectA has a build spec for a ppl that should output to ../../build/ppl but the absolute path of c:/labview/build/ppl is in the file instead. This time the relative path doesn't even ascend to the drive, everything stays within the LabVIEW folder. I'm now using some shared components as submodules in git for larger projects that follow the same relative pathing to the build folder except labview is yet again saving build specs with an absolute path.

Looks like some manual editing is in order but it sure would be nice if I didn't have to. Even having documentation to clearly explain what its deciding factors are for relative/absolute pathing would be nice as I could perhaps automated around that.