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

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

The problem is it's not "whenever possible" as I found out by going to a different root folder on the same drive. It seems as if anytime it ascends to a root drive it defaults to absolute and doesn't check if it actually changed drives or not.

I do think the "whenever possible" would be fine, at least for me, if there wasn't this bug.

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

[ugip]

@DerrickB

I couldn't agree more. Came back to LabVIEW after some years and can't believe that this is still an issue. Obviously it is.

The path will only be stored relatively when your build folder is below your project folder, in your case below "ProjectA". If it is above (like in your case) the NI "logic" will compute an absolute path, which was stupid and is stupid and has no reasoning.

You can edit the lvproj file. It's xml. So just put relative paths (3x) in the <build specifications> section. However when you change something in the build specification via the provided dialog, the NI "logic" kicks in and will make your paths absolute again.

Either NI doesn't want us to use source control tools or they don't want us to use packed libraries. Because if they do their build "logic" is flawed. 

[DerrickB]

I'll keep this thread alive as long as I have to!

2018 still having absolute path issues. Moved from an environment where everything was under D:\dev folder. All building was being done to paths within the dev folder, never even reached the D:\ drive. Move to a VM that has just a C drive. All of my projects and build specs (over 20) are all still showing D:\dev\....

Screenshot of opening a build spec from within the VM. Was a direct copy from the host D:\dev to VM's C:\dev

[wiebe@CARYA]

Manually editing the .lvproj file is the only way I've found to make the path relative again, once it's made absolute.

I really don't think it's hard to support paths like "..\builds" (relative to the project). I do this all the time when I need to specify paths.

[DerrickB]

Except that I'm doing CI and automated builds. I don't want to have to add developing yet an additional tool to go in and edit project files so that it will work from a Jenkins workspace. Or run it again if the source gets moved to a different system with different paths.

[MGiacomet]

DerrickB wrote:

"I'll keep this thread alive as long as I have to!"

I love it!

The problem is that NI refuses to (want to) understand what absolute and relative paths are. This is a concept as old as programming!

I wrote before and write again:

NI: If the user TYPES in a path (whatever it is), KEEP it and use it AS IS! Remove the code that's "fixing" the path entered by the user, in the project. Removing code is easy and won't break anyone's projects.