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]

Really?! How can LabView figure it out?? No, it can't (at least it isn't working for me...)

The only way it can work is if the Destination directory were to be allowed to contain something like ".\mydestination", then if the project is located, say, at "C:\project1" the results of the build will be output to "C:\project1\mydestination". If the project were then moved to "C:\project2", the build results will end up in "C:\project2\mydestination"

I did try you suggestion (closing the project, moving the project somewhere else and reopening it), though, and the destination folder stayed the same.

[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).

[GregR]

Computing a relative path between 2 absolute paths is actually a trivial operation and this is what LabVIEW does before saving the destination paths. So as Bob said above, though the UI always shows absolute paths they are stored as relative.

To use your example, assume that the project is in "C:\project1" and the destination path is shown as "C:\project1\mydestination". The first step is to see how many path segments match from the beginning. In this case that is 2. We then remove that many segments from each path. Since that uses the entire first path, in this case we are done. We store the remainder of the second path as a relative path producing exactly what you said you wanted ".\mydestination". 

If you are not seeing the behavior you expect, it is from something else not from the lack of using relative paths.

[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.

[MGiacomet]

Thanks for the kudos, Aristos.

Yeah, that's where the problem lies... the line from the .lvproj you mention is the problem: It makes reference to where the project was originally created (i.e., Project1), making it impossible to relocate the project somewhere else. What that line is saying is: "Navigate one level up (the ".."), then one level down (into Project1), then another one down (into build)".

To be trully a relative path, it should read just "./build", so when someone retrieves the project out of source control and places it anywhere, it still builds (in this case example) in a folder ("build") that is one level below where the project is.

Again, a tool is just a tool and should not make decisions like that, but accept what the user enters: be it an absolute or relative path. If the user enters an absolute path, use it. If a relative path, use it the way it is. This is standard practice.

[Arlon]

I just ran into this issue today after migrating from LV 2010 to a new development computer with LV 2011. Got an error when I tried to build because the destination directory was pointing to my previous working directory, which did not exist. However, it looks like they have fixed the issue in 2011. After updating the build specs and checking the project back into the repository, I checked it out to a new location and the build spec destination directory followed. Just to make sure, I did the same with my LV 2010 development computer and found the destination directory did not follow the project.

[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?